Chris McDonough wrote:
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.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?
On Mon, 2003-02-10 at 15:47, Shane Hathaway wrote:"tal:on-error" also catches all exceptions. It could be made to catch all exceptions except ConflictError, but I don't feel like that's the right solution. I think the right solution is to prevent applications from committing potentially conflicting data, even when ConflictErrors are ignored.
This doesn't seem to be a showstopper for now, but as more applications use ZODB, it could become a bigger problem.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce