[ZODB-Dev] Re: [Zope3-dev] revise transaction API

[Jeremy Hylton]

On Tue, 2004-03-30 at 15:39, Jim Fulton wrote:
> I'm removing zope3-dev from the CC
> 
> Jeremy Hylton wrote:
> > We've been having some internal discussions about how to revise the
> > transaction API for ZODB 3.3.  I posted a page in the ZODB Wiki that
> > summarizes the issues we're working on and suggests a plan of action --
> 
> I didn't see the plan of action.

The plan of action is the section under "first steps":
    - simplified module-level transaction calls
    - notifications for abort-commit event
    - restructured Connection to track modified objects itself
    - explicit transaction manager object

>  > 4. Transaction Manager -- coordinates the use of transaction.  The
>  > transaction manager provides policies for associating resource
>  > managers with specific transactions.  The question "What is the
>  > current transaction?" is answered by the transaction manager.
> 
> I guess "current" has to be interpreted wrt the transaction manager.

Yes.

>  > Current transaction
>  > -------------------
>  >
>  > The first question is "What is the current transaction?"  This
>  > question is decided by the transaction manager.  An application could
>  > chose an application manager that suites its need best.
> 
> application manager? Did you mean "transaction manager"?

Yes.

>  > Basic transaction API
>  > ---------------------
>  >
>  > A transaction module or package can export a very simple API for
>  > interacting with transactions.  It hides most of the complexity from
>  > applications that want to use the standard Zope policies.  Here's a
>  > sketch of an implementation:
>  >

> Hm.  Does this mean that the transaction manager manages individual
> transactions by thread?  This means that the definition of "current"
> transaction becomes more squishy.

Yes.  A transaction manager could associate transactions with threads,
just like the code in ZODB.Transaction does right now.  It does mean
that current transaction is only current with respect to some context,
but at least the transaction manager can provide a more careful
explanation of what it means by current.  Put another way, the
transaction manager abstracts what is currently hard-coded policy.

> What about a model where there was a TM per thread.  Then, the methods
> above would get the calling thread's TM and delegate to it.
> Similarly, one could create a new TM and use it to manage changes
> independent of thread perhaps.

I think I follow the end goal, but not the mechanism you propose.  If we
had a TM per thread, it seems like it would be harder to implement a
policy of one transaction independent of threads.

The current proposal would allow the application to change policy by
installing a new transaction manager.  The simplest transaction manager
would just have a single "current" transaction that was independent of
thread.  I imagine we'd implement that so that we could use it in
conjunction with db.open().

>  > The individual transaction objects should have a register() method
>  > that is used by a resource manager to register that it has
>  > modifications for this transaction.  It's part of the basic API, but
>  > not the basic user API.
> 
> We had use cases for allowing resource managers to be able to register
> with transaction managers, to be notified of transaction-relevent
> events.  I think that this was important for MVCC to be able to
> invalidate historical objects at the end of read transactions.

There's a separate section on registration and notification.  It
suggests having a different set of registrations for synchronization. 
I've implemented that by allowing a Connection to register itself with a
TM; the Connection provides beforeCompletion() and afterCompletion()
callbacks that are called before and after a commit or abort.

>  > Extended transaction API
>  > ------------------------
>  >
>  > There are a few other methods that might make sense on a transaction:
>  >
>  > status() -- return a code or string indicating what state the
>  > transaction is in -- begin, aborted, committed, etc.
>  >
>  > note() -- add metadata to txn
>  >
>  > The transaction module should have a mechanism for installing a new
>  > transaction manager.
> 
> We also need the ability to store application-defined data.

Right.  In the working implementation, we've still got the _extension
code from current ZODB.  Is that code used anywhere?

>  > ZODB Connection and Transactions
>  > --------------------------------
>  >
>  > The Connection has three interactions with a transaction manager.
>  > First, it registers itself with the transaction manager for
>  > synchronization messages.  Second, it registers with the current
>  > transaction the first time an object is modified in that transaction.
>  > Third, there is an option to explicitly pass a transaction manager to
>  > the connection constructor via DB.open(); the connection always uses
>  > this transaction manager, regardless of the default manager.
> 
> Is this a transaction manager, or a transaction?

That's a transaction manager.  A transaction only lasts from a begin to
a commit.  Would it be useful to have a connection only be allowed to
participate in a single transaction?

Jeremy