Is there any way to influence the order of transaction aborts when you hijack the transaction mechanism in a similar way as Shared/DC/ZRDB/TM.py does? I have Folder and File like classes which make changes on the file system as a part of their operation. When within a transaction I make multiple changes to these objects and the transaction is aborted, I have to do some cleanup in reverse order as these operations were executed. AFAIK, the p_jar.abort() calls are made in the same order as the objects were registered in the transaction. Regards, Sandor
shared/dc/zrdb/tm does not hijack the transaction mechanism it integrates with it. you should coalesce txn integration for your objects into a single txn integrator so you needn't depend on transaction message/jar ordering. -kapil On Tue, 2004-04-20 at 11:35, zope@netchan.cotse.net wrote:
Is there any way to influence the order of transaction aborts when you hijack the transaction mechanism in a similar way as Shared/DC/ZRDB/TM.py does? I have Folder and File like classes which make changes on the file system as a part of their operation. When within a transaction I make multiple changes to these objects and the transaction is aborted, I have to do some cleanup in reverse order as these operations were executed. AFAIK, the p_jar.abort() calls are made in the same order as the objects were registered in the transaction.
Regards, Sandor
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
participants (2)
-
Kapil Thangavelu -
zope@netchan.cotse.net