[ZODB-Dev] Re: [Persistence-sig] "Straw Man" transaction API

[Phillip J. Eby]

I just discovered an interesting (design?) flaw in both my "Straw Man" API
and ZODB4 regarding savepoints...

If you savepoint the transaction with participants p1 and p2, and then
participant p3 joins the transaction *after* this, the created savepoint
object has no way to know how to rollback p3, if it's rolled back.

It seems some additional complexity in the join method and the savepoint
aggregation are required.  :(


At 10:58 AM 8/1/02 -0400, Jeremy Hylton wrote:
>>>>>> "AB" == Anthony Baxter <anthony@interlink.com.au> writes:
>
>  >>>> Barry A. Warsaw wrote
>  >> Say you had savepoint(t1), savepoint(t2), and savepoint(t3) where
>  >> t1 < t2 < t3.  Then you rolled back savepoint(t1) and then try to
>  >> rollback savepoint(t3), you'd get an exception right?
>
>Yes.  RollbackError.
>
>  AB> If you have multiple savepoints in the same transaction, should
>  AB> you be allowed to roll back the one that's not the most recent?
>  AB> To my brain, this doesn't make sense...
>
>It does make sense.  It's all about saving partial progress so that
>you can return to it later if something goes wrong.  Nested
>transactions are an example of something that wants to rollback to
>arbitrary earlier savepoints.  If part of a subtransaction fails, you
>need to rollback to th beginning of the subtransaction.  You need not
>abort the entire transaction, because some part of the application can
>recover and continue from the last savepoint.  In particular, the
>state of persistent objects gets rollback but the total state of your
>application (e.g. control flow, non-persistent local variables, etc.)
>is not.