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
_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
