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): try: if self._mysql_lock: self.db.query("SELECT RELEASE_LOCK('%s')" % self._mysql_lock) self.db.store_result() if self._transactions: self.db.query("ROLLBACK") self.db.store_result() else: LOG('ZMySQLDA', ERROR, "aborting when non-transactional") finally: # just ignore the exception for "release unlocked lock" try: self._tlock.release() except: pass 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? > > Thanks, > > - C > -- _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )