zpatterns-0.4.0a5: problem with unregistering transactionals
hello, I have a case where Transactional._unregister is called without Transactional._register being called, raising an exception in Transaction._unregister and then in ZODB.Transaction.Transaction.__del__, causing Zope to dump core when it is run as a daemon (because python notifies of the unhandled exception by writin to stderr) I have not yet found why (and how?) an object is Transactional._unregistered without being Transactional._registered before. (I even did not know about the existence of these methods!) But until I understand, this patch allow me to stay alive: --- Transactions.py.orig Thu Jul 20 09:58:00 2000 +++ Transactions.py Wed Jul 26 11:12:25 2000 @@ -45,7 +45,8 @@ self._v_registered = 1 def _unregister(self): - del self._v_registered + try: del self._v_registered + except: pass # From here down, override as you see fit... more to come when I have the time to figure out the problem. it might be a bug in zpatterns :-) regards, jephte.clain@univ-reunion.fr
Jephte CLAIN wrote:
I have a case where Transactional._unregister is called without Transactional._register being called, raising an exception in Transaction._unregister and then in ZODB.Transaction.Transaction.__del__, causing Zope to dump core when it is run as a daemon (because python notifies of the unhandled exception by writin to stderr)
I have not yet found why (and how?) an object is Transactional._unregistered without being Transactional._registered before. (I even did not know about the existence of these methods!) But until I understand, this patch allow me to stay alive:
Ok, so ZPatterns.Transactional._unregistered method is called twice for a ZPatterns.Transactional object when an exception is raised and the ZPatterns.Transactional object has not be freed: once from the ZODB.Transaction.abort method, once from the ZODB.Transaction.__del__ method which call abort if objects to be aborted remain in the zodb transaction aware object The call is made twice for DataSkins and for TransientMapping (as far as I know, they are at the moment the only Transactional objects in zpatterns) for example, try this DTML code in a specialist: <dtml-with "getItem(key='whatever key you have in the specialist')"> <dtml-raise> </dtml-raise> </dtml-with> without my patch, Zope should display 'uncatched exceptions in Transation object' so what now? I'm lost. Is this normal or not? Is my patch sufficient (ignore attempts to abort the object twice by trapping exceptions in _unregister). What about Transactional.abort which check for tpc_entered? Why is tpc_entered never set to 0? please help regards, jephte.clain@univ-reunion.fr
Question... Are you on 2.1.x or 2.2? Also, in your example, tpc_entered is not set because tpc_entered is only true if the transaction commit process (tpc = two-phase commit) has been started. At 11:53 AM 7/27/00 +0400, Jephte CLAIN wrote:
Ok, so ZPatterns.Transactional._unregistered method is called twice for a ZPatterns.Transactional object when an exception is raised and the ZPatterns.Transactional object has not be freed: once from the ZODB.Transaction.abort method, once from the ZODB.Transaction.__del__ method which call abort if objects to be aborted remain in the zodb transaction aware object The call is made twice for DataSkins and for TransientMapping (as far as I know, they are at the moment the only Transactional objects in zpatterns)
for example, try this DTML code in a specialist:
<dtml-with "getItem(key='whatever key you have in the specialist')"> <dtml-raise> </dtml-raise> </dtml-with>
without my patch, Zope should display 'uncatched exceptions in Transation object'
so what now? I'm lost. Is this normal or not? Is my patch sufficient (ignore attempts to abort the object twice by trapping exceptions in _unregister). What about Transactional.abort which check for tpc_entered? Why is tpc_entered never set to 0?
participants (2)
-
Jephte CLAIN -
Phillip J. Eby