Dennis Allison wrote at 2005-11-14 18:21 -0800:
... 2005-11-14T06:20:40 ERROR txn.4100 Error in tpc_abort() on manager <MultiObjectResourceAdapter for <Products.ZMySQLDA.db.DB instance at 0x42c6a52c> at 1186514860> Traceback (most recent call last): File "/usr/local/src/zope/Zope2.8/lib/python/transaction/_transaction.py", line 462, in _cleanup rm.tpc_abort(self) File "/usr/local/src/zope/Zope2.8/lib/python/transaction/_transaction.py", line 548, in tpc_abort self.manager.tpc_abort(txn) File "/usr/local/src/zope/Zope2.8/lib/python/Shared/DC/ZRDB/TM.py", line 64, in abort try: self._abort() File "/opt/zope/zproducts/standard/ZMySQLDA/db.py", line 389, in _abort self._tlock.release() error: release unlocked lock
Thus, you find all places where "_tlock" is "acquired" or "released" and analyse what can cause a "_tlock" release without a previous "_tlock" acquire... It looks like a bug in "ZMySQLDA/db.py", maybe caused by an unexpected sequence of "TM" (Transaction Monitor) calls.
.... Questions: ~~~~~~~~~~
What is the cause of the locking problem? Does ZMySQLDA/MySQL-Python/Zope have some path which should have called begin to get a lock and did not?
Probably...
What needs to be done to make session variables stable?
You are aware that any exception that bubbles up to the ZPublisher (especially "raise Redirects", "Unauthorized", ...) will abort the transaction -- the session will not be modified ? Furthermore, sessions are inherently prone to potential race conditions. Are you sure that the problem arises from serial cases?
Does the Temporary Storage method need to be extended to allow for rolling back a transaction?
All ZODB storages are fully transactional... There is no switch to turn it on and off; it is always on. -- Dieter