[Zope] ZODB.POSException.ReadConflictError

[Chris McDonough]

On Tue, 2005-05-03 at 09:18 -0700, egroup at mac.com wrote:

I cc'ed Tim Peters on this, perhaps to his chagrin, but he seemed to be
interested in this. ;-)

> Thank you for that reference (I have an older dead trees version). Now 
> I understand that these errors happen, but what I don't understand is 
> why my users see them ("The requests which experience conflict errors 
> will be retried automatically by Zope, and the end user should *never* 
> see one." emphasis in original).

Yes.  Although that's an intent and not a promise.

> Is it simply a matter of too much traffic for the server? This is a 
> dual 2.3 GHz box, 2G of RAM, 10,000 RPM SCSI drives (two, mirrored as 1 
> logical RAID 1 drive), serving 8,000 members (now about 1,000 new 
> members a month, hence the urgency), 80,000 visits per month, 400,000 
> page views per month. Is it time to dip my toe into ZEO?

ZEO may help.  But may not help here, especially if you put your session
data in it.  The main reason for read conflict errors are that a
particular transaction is "slow" and that other simultaneous
transactions come along and modify the data which the slow transaction
is trying to read.  When the slow transaction figures this out, it bails
out.  ZEO actually just makes it slower because the data involved in a
transaction typically needs to be encoded and decoded for travel across
a network.  That said, if you have multiple appservers, and you keep
your session configuration as the default, each appserver will have its
own (non-ZEO)_ session database, and thus will presumably be less prone
to conflict due to the disbursement of sessions across multiple
machines.  But you'll need to keep "session affinity" (every subsequent
request from a user with a particular browser id needs to go to the same
appserver).  I use pound for this.

You should try to determine a pattern to the errors your users are
seeing (many simultaneous requests to a specific resource).  This may be
better solved by changing application code to do fewer session accesses
or might be solveable via changing sessioning configuration.

See http://www.plope.com/Members/dunny/conflicts/view for an idea about
what sort of conflict rates to expect under torture situations.
Apparently your configuration has managed to torture sessions more than
our torture tests, however, because I've personally not managed to have
Zope try more than three times to complete a request that encounters a
sessioning conflict during this type of testing in the "default"
configuration.

- C