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
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
