We had been plagued with a threading error which manifests itself
as an exception reporting "release unreleased lock". At Andy's
suggestion I added code to catch the exception in the appropriate
place in ZMySQLDA --
Here's the code from db.py ---
The code probably should be specific to the unreleased lock exception
since, presumably, the code could throw other exceptions. On the whole,
I think this is a ban-aid solution.
def _abort(self, *ignored):
self.db.query("SELECT RELEASE_LOCK('%s')" %
LOG('ZMySQLDA', ERROR, "aborting when non-transactional")
# just ignore the exception for "release unlocked lock"
On Sun, 27 Nov 2005, Chris McDonough wrote:
> > Chris,
> > A helpful suggestion. The commit errors I've been seeing have to
> > do with the intereaction of the ZODB, MySQL, session variables, and
> > conflicts.
> 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 - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -