On Tue, 2003-02-11 at 04:13, [EMAIL PROTECTED] wrote: > Chris McDonough wrote: > > Could this be done by initializing a dictionary at startup keyed on > > thread-id that a ConflictError exception's __init__ could stick a marker > > into, then checking that dictionary at commit time and disallowing the > > commit if the marker still existed? > > Yes, but Transaction objects are already keyed on the thread ID, so I > think you just have to set a "doomed" flag on the transaction. Attempts > to commit doomed transactions result in either ConflictError or > "DoomedTransactionError". ;-) Aborting the transaction (or beginning a > new transaction) resets the flag. > > Shane
The doomed flag is the way zodb4 works. Each transaction has a status flag that can be one of: active, preparing, prepared, failed, committed, aborting, and aborted. Actions are only allowable in certain states. The only thing you can do to a failed transaction is abort it. And the only thing you can do to a prepared transaction is commit or abort it. I'd like to backport that to ZODB3, but I need to finish the transaction package for ZODB4 first. If the current problem is perceived to be a significant risk, we could increase the priority of the backport. One downside is that some people do strange things with transactions, like joining them during the commit; that doesn't work in ZODB4. Jeremy _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
