[Persistence-sig] "Straw Man" transaction API

[Phillip J. Eby]

At 08:36 PM 7/29/02 -0400, Jeremy Hylton wrote:
>Last week, I worked out a revised transaction API for user code and
>for data managers.  It's implemented in ZODB4, but is fairly
>preliminary code.  I imagine we'll revise it further, but I'd like to
>describe the changes briefly.

I'm not sure if this new API is in relation to the proposals on this list 
or not, but I'm curious how this affects a few things:

* The need for participants to join every transaction.  This is one of my 
top complaints about the existing API.  I have *never* had a single 
application where I couldn't simply register all participants to the 
transactions at or near startup, and never need to do so again -- if it 
weren't for the fact that the transaction API doesn't work that way.  I 
have to write code that tracks whether an object has been registered with 
*this* transaction, and knows when the transaction is over so that it knows 
it needs to register again.  Could we at least have a "permanent join" 
operation?

* Arbitarily nested, cascading participants.  Does this support 
them?  How?  I don't see any mention of the issues in the interfaces.

* If a data manager can't support rollback to a savepoint, what does it return?


 >(The need for notify-on-read, BTW, is to support higher isolation
 >levels than ZODB currently supports.)

And to support delayed loading of attributes by multi-backend data 
managers.  Although to support that, there'd need to be the opportunity to 
override the attribute value that was read.