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

for example, try this DTML code in a specialist:

<dtml-with "getItem(key='whatever key you have in the specialist')">

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


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to