[ZODB-Dev] Re: [Zope-dev] Re: post publishing hook

[Jim Fulton]

Jeremy Hylton wrote:
> On Apr 4, 2005 10:38 AM, Jim Fulton <jim at zope.com> 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:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org