[Persistence-sig] Nested Transactions

[Jeremy Hylton]

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

  PJE> At 05:24 PM 7/22/02 -0400, Jeremy Hylton wrote:
  >> I would like to see arbitrarily nested transactions supported in
  >> the next generation transaction API.

  PJE> Could you add some more specifics?  For example, what happens
  PJE> if a transaction participant can't support nested transactions?
  PJE> I gather that this capability is not exactly common, even among
  PJE> SQL databases.

I gather you want more specifics about the API, which I'll post as
soon as I work them out :-).  The general idea is clear enough, I
think.  A larger transaction can be composed of several components
transactions, each of which is an atomic action.  This approach can be
applied recursively.

If the backend doesn't support it, then the application gets an
exception when I tries to use the feature.  The APIs should support
it, though, so that applications can be written against it.

I didn't think nested transactions were that uncommon, BTW.  At least
some of the EJB servers support them.

The two interface ideas I have are a savepoint() method or a way to
create a new transaction and specify a parent.  A savepoint() method
would return an object with a rollback() method.  When you call
savepoint(), you commit a subtransaction.  If you call rollback(), you
roll back changes to the savepoint.  I think this API can support
arbitrarily nested transactions, although the application will have to
work to manage the savepoint objects.

The other option seems simpler for nesting, because you explicitly
begin a new transaction for each atomic subaction.  The problem with
it is that the current transaction API doesn't have an explicit begin
phase.  (Is there a common pattern for RDBMS?  I've used some that do
an implicit BEGIN WORK and some that require an explicit one.)

Jeremy