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 patch fixes).

These particular problems do not appear to be related to the ZODB/ session variable/conflict issues, but I cannot completely exclude them since leaks
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.

What is?


- C

Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to