On Tue, 2003-02-11 at 12:10, Shane Hathaway wrote:
> I added a test to testZODB.py on a new branch 
> (shane-conflict-handling-branch) that exercises the conflict handling 
> bug.  The test currently fails.  It might be simpler to go with Toby's 
> implementation for now: add a "veto" object to the transaction that 
> refuses any attempt to commit.  But maybe your transaction states are 
> better.  Let me know what you want to do.

I'd like to do the transaction states, because it would keep the code in
zodb3 and zodb4 similar.  Unless there's a reason to think there are
problems with the transaction state approach.

I didn't look carefully at the test, but if I remember the discussion
last time around, the problem is with read conflicts caught outside of
2PC.  In that case, we either need to mark the connection so that it
votes no when it gets to prepare() or we need to veto() method.  I'd
prefer the vote-no-in-prepare because it keeps the API smaller, but
veto() isn't so bad; maybe it's better to stop the transaction quickly.

We have a similar need when things go wrong inside the persistent
machinery.  I can't recall the details, but I think there are comments
in the code about what happens when loading an object fails -- some
state transition fails at any rate.  In that case, the transaction
really needs to be marked as failed and further actions prevented.


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to