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

[Shane Hathaway]

Jeremy Hylton wrote:
>>>>>>"PJE" == Phillip J Eby <pje@telecommunity.com> writes:
>>>>>
> 
>   PJE> I just discovered an interesting (design?) flaw in both my
>   PJE> "Straw Man" API and ZODB4 regarding savepoints...
> 
>   PJE> If you savepoint the transaction with participants p1 and p2,
>   PJE> and then participant p3 joins the transaction *after* this, the
>   PJE> created savepoint object has no way to know how to rollback p3,
>   PJE> if it's rolled back.
> 
>   PJE> It seems some additional complexity in the join method and the
>   PJE> savepoint aggregation are required.  :(
> 
> Interesting problem :-).
> 
> If a participant joined after a savepoint, would it be sufficient to
> abort that participant?

Here's another way to look at this.  All IMHO.

I really don't think of ZODB 3 as needing "subtransactions" or even 
"savepoints".  The only subtransaction-related need I've ever seen in 
ZODB applications is the ability to move the current set of changes out 
of RAM.  No ZODB application that I've seen uses 
get_transaction().abort(1).  Applications use 
get_transaction().commit(1) mainly for the purpose of conserving RAM.

In the future, ZODB applications could access this kind of functionality 
through some other API, perhaps "jar.swapOutChanges()" or something, 
making the intent clearer and removing the dependency on 
subtransactions.  To the uninitiated, "commit(1)" does not express the 
intent of conserving RAM.

So perhaps the initial outcome of this SIG does not need to account for 
subtransactions and/or savepoints.  Is it a real need?

Shane