-> It sounds like a glitch in the DA. Well, this is what I found. The attribute "lock" is being accessed in the _abort method, which is: -------------------------------------- def _abort(self, *ignored): try: self.db.query("ROLLBACK") self.db.store_result() finally: self.lock.release() -------------------------------------- It's failing in the finally: block, trying to access self.lock.release(). But this is all I see in the __init__ method of the class DB(TM): definition: self._lock = allocate_lock() In fact, I see this "self._lock" attribute, *with the underscore*, seven other times in the the file. But I see a self.lock attribute appear three times in the file -- but never in the __init__ method. So, as I understand it, unless self.lock appears in the __init__ method of the parent class "TM", then "self.lock" is a typo and should be "self._lock". Is that a valid assumption? Notice that TM does not declare self.lock: [root@dev ZRDB]# pwd /usr/share/zope/lib/python/Shared/DC/ZRDB [root@dev ZRDB]# grep -i lock TM.py [root@dev ZRDB]# Should I change those three instances of self.lock to be self._lock? Also, what is the last known *WORKING* version of the Z MySQL Database Adapter? This seems like a showstopper bug, but it's in a product that has to be pretty popular... -> Alternatively, delete and recreate the DA object. This I do not understand. How would simply deleting and re-creating an instance fix a bug in the code? Thanks, Derek