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

[Phillip J. Eby]

At 12:23 PM 9/13/02 -0400, Shane Hathaway wrote:
>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).  

I *almost* used it once.  :)

The only use-case I've ever had for using it (and I never actually did use
it for this), was to handle a batch of operations from a single form
submit, with each line item handled as a separate rollback, so that the
resulting page would list errors for line items that failed, but line items
that succeeded would be committed.  That is, a try/except block around each
line item, that set a savepoint before the item, and rolled back to the
savepoint if an exception occurred, append the exception to a list, and
proceeded to the next line item.


>Applications use 
>get_transaction().commit(1) mainly for the purpose of conserving RAM.

ZPatterns-based apps also do it to synchronize external state (i.e. an
RDBMS) with internal state (objects), so that queries performed against the
external state will reflect the current internal state.

Naturally, this is a hack.  :)

In PEAK, "query jars" will directly request that their underlying "storage
jars" 'flush' themselves to external storage before performing a query, so
a global hack of this kind is not required.


>In the future, ZODB applications could access this kind of functionality 
>through some other API, perhaps "jar.swapOutChanges()" or something, 

In PEAK's case, this would be available via a Rack.flush() operation, so I
see your point.


>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?

Good point.  I can live without them entirely.  Evidently, so can most Java
developers (JTA doesn't require, nor specify how to provide, nested
transactions).  I don't see anything wrong with dropping this from a
hypothetical PyTA; we can always come back a year or two from now and
define a standard "extension" for this after there has been field
experimentation/experience.