Jeremy Hylton wrote:
On Apr 4, 2005 10:38 AM, Jim Fulton <[EMAIL PROTECTED]> wrote:

If you register a synchronizer with the transaction manager, it's
beforeCompletion() method will be called immediately before changing
the transaction's state to committing.  This hook was intended in part
to support use cases like "do something magic to the transaction
before it commits."  It looks like the registerSynch() method of the
transaction manager is undocumented, but that is an oversight.

Ok, and I see that beforeCompletion(t) has to check t.status to find out
when it is called (if the transaction is ACTIVE it's ok, otherwise it's
been called by abort() -- the fact that abort() calls it should probably
be documented).

I think that this is not the right mechanism. It's not really intended for application code and is far to complex for what is, IMO, a very simple case.

I don't have anything invested in the decision, but synchronizers were
intended to support this use case.  They provide a way for arbitrary
application code to observe the transaction boundaries without
pretending to be a data manager.

OK, maybe I missunderstood synchronizers. Is there any documentation for them beside the source?

From reading the source. they don't seem to fit the use case very well:

- They are registered with the TM and are called for subsequent
  transactions until they are unregistered.  This is not what we want
  here.  We want hooks to be called only if the current transaction
  commits.  We want to throw the hooks away at the end of the transaction.
  It's not obvious how to make this work with synchronizers.  (I suppose
  the syncronizer could save the transaction it cares about
  and unregister itself if it sees another.  This is a lot of bother.)

- The synchronizers are called on a commit *or* an abort.
  We want hooks to be called on a commit only.

- Synchronizers have to provide 2 methods, beforeCompletion
  and afterCompletion.  This means that synchornizers have to
  be instances with methods.  For before-completion hooks
  we want to be able to just supply functions.  We'd
  also have to provide a dummy after completion method that
  we don't care about.

My understanding is that synchronizers were added to support
MVCC. They are well suited to supporting data managers
that need to know about transaction boundaries.

I think the use case here would be better served by simple
hooks of the sort I proposed.


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to