[Persistence-sig] "Straw Man" transaction API

Phillip J. Eby pje@telecommunity.com
Mon, 15 Jul 2002 11:36:26 -0400


At 09:59 AM 7/15/02 -0400, Jim Fulton wrote:
>
>This is an interesting proposal. I'll me interested to see
>more discussion on it. It appears to shift responsability for
>management of individual object changes further into the resource
>managers, which is fine.

My thought on this was that the resource managers know more about their
objects than the transaction does.  Also, this should greatly reduce the
complexity of the commit operation compared to ZODB's Transaction.  And
most important, it *decouples transactions from the persistence framework*.
 ZODB's Transaction has to know how to get at an object's storage manager,
while Strawman doesn't.


>I'm a little fuzzy on participants that write data to other participants.
>The notion that they flush data on begin_savepoints feels a little
>brittle to me. If the participant the flush to does any significant work
>on begin_savepoint, then it appears that things could happen in an
inconvenient
>order and cause problems.

The assumption here is that things which do "real" work (as opposed to
writing to another participant) should trap the second message.  In other
words, there's a pretty solid distinction between "delegating" participants
and "direct" participants, in terms of their behavior.  The use cases I'm
looking at are one or more persistence mechanisms writing to a storage
mechanism.  At some point, you have to "bottom out" to "real" storage, and
that's where you handle the ending of a savepoint or commit.


>Is the transaction info cleared at transaction boundaries?

If you mean the setInfo() stuff, yes.  I probably should've documented
that, but then if I documented *every* assumption I made, the doc would've
been twice the size.  :)