A helpful suggestion. The commit errors I've been seeing have to
do with the intereaction of the ZODB, MySQL, session variables, and
So the patch that Andy sent over is a fix that prevents the mysql
adapter from raising an error when a conflict exception occurs? Do
you know if that error only happens after a conflict exception occurs
or can it happen without the presence of conflict exceptions? (I'm
curious because I also use the adapter and I'd like to know what the
These particular problems do not appear to be related to the ZODB/
variable/conflict issues, but I cannot completely exclude them
easily cause failures far away from where the fault lies.
I'm afraid I can't parse that sentence fully. But I'll try to
interpret as best possible. ;-)
I think I've said this before but it in case not... the use of
sessions is only one place where conflict errors can be generated.
Conflict errors are "normal" in any system that causes writes to a
ZODB database. If your application does any writes to a ZODB
database at all (besides the writes that occur from use of the
sessioning machinery), and the mysql adapter wasn't tolerant of
conflict errors, you'd be getting the same result, they'd just
probably happen further apart.
That said, I certainly am interested in making fewer conflicts errors
go unresolved when the sessioning machinery is used. If you were to
tell that you've taken the steps I've already suggested about
reducing the potential for conflicts during session usage (use 2.8
with mvcc, turn external housekeeping on, bump up the resolution
time, local zodb db for sessions), and you observed that you're still
having "too many" conflicts, I'd try to take some action, although to
do so I might still need to request your help in providing data about
your conflict rates.
It certainly is a worthwhile thing to check and monitor.
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -