Thanks again Chris for the helpful comments. The navigation_box, in this context is just a table which is rendered into a frame in our standard frameset. It is not an iframe. In the sense I used them below, a transaction and a request are the same thing. This follows from the fact that each request is managed as a single transaction. Perhaps it would have been a better choice of words to use "request". I suggested breaking the request into two requests as one way to help manage conflicts. Only the first part of the the split request would reference the session variables, so the window of opportunity for a session variable conflict would be smaller even though the number of requests is larger. And, sigh, you are probably right--it may be time to abandon the standard release session implementation and roll our own. On Wed, 21 Dec 2005, Chris McDonough wrote:
Write conflicts happen for a transaction. In Zope, there is one transaction per request.
There are two distinct sections to the navigation_box transaction.
There's a transaction for something named "navigation_box"? Is this an IFRAME?
One where the session variables are read and a second where they are used. To minimize conflicts, the what is now a single tranaction should be split into two separate transactions.
Are you maybe misusing the term "transaction" here? If this logic all happens in the course of a single request, it all happens in the same transaction unless that request causes, say, the reload of a frame.
There is a concept of a transaction here. But it doesn't have anything to do with what happens during the course of a single request unless you explicitly try to control transactions, which is almost never a good idea.
Any thought as to how to do that? If navigation_box were broken into two separate methods, say nav_box1 and nav_box2, how does nav_box1 commit itself and then transfer control and data (a session variable snapshot) to nav_box2 as a new transaction?
I suspect I don't understand what this would achieve. Having more transactions will cause more conflicts. Conflicts happen as a result of conflicting changes in two transactions.
I would guess that if nav_box1 redirects to nav_box2 a new transaction is initiated and the old one committed. Is that correct? And is there a better way to get the same effect?
I have no idea, sorry.
I think maybe what you might want to do here is to not use builtin Zope sessions. ;-) Zope sessions rely on ZODB and are transactional. If they didn't rely on ZODB, you wouldn't be getting conflict errors. If they weren't transactional, you probably wouldn't notice.
Might be time to cut bait here. We've been talking about this for months. ;-) I think someone wrote a relational database backend for the sessioning API some time ago. You may want to give that a shot.
- C
--