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

Jeremy Hylton jeremy@alum.mit.edu
Wed, 31 Jul 2002 16:09:10 -0400


>>>>> "SH" == Shane Hathaway <shane@zope.com> writes:

  SH> On Wed, 31 Jul 2002, Jeremy Hylton wrote: I would like this
  SH> interface to be called ITransactionParticipant.  There are many
  SH> interesting kinds of objects that would be interested in
  SH> participating in a transaction, and not all of them have the
  SH> immediate responsibility of storing data.  But the names you
  SH> chose for the methods are very clear and concise, I think.
  >>
  >> I think IResourceManager is probably better (see above).  I wish
  >> I could take credit for the names, but I just grabbed them from
  >> the Gray & Reuter book :-).

  SH> Ok, but some of the things we'd like to tie into transactions
  SH> don't really manage data/resources.  For example,
  SH> "CommitVersion", "AbortVersion", and "TransactionalUndo" objects
  SH> (from ZODB 3) just listen for the "commit" message.  Then they
  SH> ask an object that really is responsible for data/resources to
  SH> do something.

  SH> I don't have the book, but my uneducated guess is that we're
  SH> working with something a little more general than what Gray and
  SH> Reuter proposed.

I think that "resource manager" is a suitably generic term.  Do we
really care whether the thing-with-a-commit-method manages an object
or not?  I don't think it makes things clearer to distinguish between
the overall class of resource managers and the subset that manage
their own objects.

There are a bunch of ways to split this hair:

The XXXVersion and TransactionalUndo objects really do have resources
-- the names of the version or the transaction id.

The Connection doesn't manage objects either, the storage does.  So
the storage is a resource manager (except that it doesn't support the
resource manager API) and all these things layered on top constitute
nested resource managers.

All of the above are resource managers.  It's not appropriate to ask
how these managers work, because that's not part of the transaction
API.  A resource manager is just a black box with prepare(), commit(),
etc. methods.

Jeremy