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?

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

Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to