[Persistence-sig] "Straw Man" transaction API

[Jeremy Hylton]

>>>>> "PJE" == Phillip J Eby <pje@telecommunity.com> writes:

  PJE> 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.

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

  PJE> * The need for participants to join every transaction.  

How would you like this feature to interact with custom policies for
mapping threads to transaction ids?  If ZODB keeps with its default
policy, it may be useful for a ZODB Connection (resource manager) to
join every transaction run by a particular thread.  However, the
Connection would need to stop joining at some pount.

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

It doesn't support them at all, as much previous discussion has
illustrated.  I'd like to address that in a separate email.

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

Good question.  Here's my first guess at an answer: It returns None.
If multiple resource managers participate in a transaction and one
doesn't support savepoints, then the application can't rollback the
savepoint.  The other resource managers may execute the savepoint, but
rollback is impossible.

(In the case of ZODB, it can be useful to execute a savepoint
regardless of whether it is rollback, because it allows modified
objects to become ghosts.)

I'm not sure if it's useful to provide an introspection capability to
see if rollback is allowed.

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

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

It's possible to define a custom __getattr__ on a Persistent
subclass.  Is that enough?

Jeremy