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):
            if self._mysql_lock:
                self.db.query("SELECT RELEASE_LOCK('%s')" % 
            if self._transactions:
                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?
> Thanks,
> - C


Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to