John Eikenberry wrote:

> Toby Dickenson wrote:
> > Read conflicts occur if a change is committed in between the start of a 
> > transaction, and the transaction needing to load the object. A workaround to 
> > reduce the number of read conflicts is to touch the objects that are likely 
> > to change early in the transaction.
> Thanks for the tip. My sessions test script had a sleep() call right after
> the transaction commit, thus making it right at the beginning of the next
> transaction. Moving it to right before the commit (after all the session
> tests) pretty much eliminated all the read conflict errors. Just get a
> standard ConflictError occasionally now (not nearly as often).

This turned out to be better than I thought. After nearly 3 hours of
constant abuse I have yet to see a ReadConflictError and have yet to get
either the load() or get() KeyErrors, previously I could force one of these
in a 2-3 minutes of abuse.

Our live sessions code uses the sessions about half to two-thirds of the
way through the transaction. Given what can happen in that first half,
there is easily plenty of time for read conflicts. I think I might be able
to move our session use to the beginning of the transaction (just storing
stuff in the REQUEST object for later usage) and hopefully fix our issue.

The KeyErrors happen under similar circumstances to the ReadConflictErrors.
The significant difference being that the KeyErrors happen after the
transience timeout has occured. When I am running with the
LowConflictConnection disabled the KeyErrors occur in the
Connection.setstate method at line 509, before the ReadConflictError check.

So say you have 2 threads; A and B.  If A starts first, hits the session
code and triggers a _housekeep() call during which time B has started but
has not reached the Sessions code until after _housekeep() has finished.
When it does reach the sessions code, you get the KeyErrors. 

Sound reasonable?


John Eikenberry [EMAIL PROTECTED]
"A society that will trade a little liberty for a little order
 will deserve neither and lose both."
                                          --B. Franklin

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to