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

[Jeremy Hylton]

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

  >> The APIs look like this:
  >>
  >> class ITransaction(Interface): """Transaction objects."""
  >>
  >> def abort(): """Abort the current transaction."""
  >>
  >> def begin(): """Begin a transaction."""
  >>
  >> def commit(): """Commit a transaction."""
  >>
  >> def join(resource): """Join a resource manager to the current
  >> transaction."""

  SH> By "resource manager" do you mean "IDataManager"?

I have used these terms somewhat interchangeably, yes.  I think
"resource manager" is the more widely used terminology.

  >>
  >> def status(): """Return status of the current transaction."""

  SH> What kind of object would status() return?  Who might make use
  SH> of it?

I expect status returns values from an "enum" with values like
in-progress, committed, aborted.

  SH> Also, I'd like to see some way to set transaction metadata.

I didn't include any transaction metadata in the generic Transaction
interface.  I wasn't sure how generally applicable that was.  Instead,
I created a subclass of Transaction in ZODB that has the old ZODB
interface. 

  SH> I would like this interface to be called
  SH> ITransactionParticipant.  There are many interesting kinds of
  SH> objects that would be interested in participating in a
  SH> transaction, and not all of them have the immediate
  SH> responsibility of storing data.  But the names you chose for the
  SH> 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 :-).

  >> class IRollback(Interface):
  >>
  >> def rollback(): """Rollback changes since savepoint."""
  >>
  >> I think the rollback mechanism will work well enough.  Gray and
  >> Reuter explain that it can be used to simulate a nested
  >> transaction architecture.  Thus, I think it's a reasonable
  >> building block for the nested transaction API.

  SH> Making rollback operations into objects is a little surprising,
  SH> but as I don't fully understand the ideas behind nested
  SH> transactions, I'm sure there's a reason for rollback objects to
  SH> exist. :-)

The database needs some object to represent the particular savepoint.
A transaction could call savepoint() three times and have three
different states it could rollback to.  I decided a rollback object
was clearer than a rollback() method on the transaction that took a
savepoint_id argument.

  SH> It seems to me that the data manager should register to receive
  SH> specific notifications.  Some data managers are only interested
  SH> in knowing when an object is moving from "ghost" to "saved" and
  SH> from "saved" to "changed" state (such as ZODB); others might
  SH> want more events, like being notified the first time an object
  SH> is read in a transaction or receiving notification of *every*
  SH> attribute change.  Supporting the extra events in C only incurs
  SH> a speed penalty if the data manager requests those events.

That's a good idea.  We need to flesh out all the events that might be
part of the persistence framework, then we can see how that percolates
up into the transaction API.

Jeremy