[Zope] Zope 2.8.4 strange behavior

[Dennis Allison]

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
> 

--