[ZODB-Dev] afterCommitHook

[Julien Anguenot]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim Peters wrote:
> [Victor Safronovich]
> 
>>...
>>it  should  be  better  to  add  addAfterCommitHook  to  transaction
>>as in addBeforeCommitHook.
> 

yup it could be really useful to trigger non transactionnal code from
there. We might use this in here with our CPSRelation product and the
rdf db we are using. I could find a project to test this in real life :)

> 
> Sounds like a reasonable idea to me.  Who wants to implement it?  (It should
> be done on a branch off of current ZODB trunk, which is current ZODB 3.6
> development.)

I can take care of this if nobody else is interested to do it. I can
surely do this by the end of the week.

> 
> The first thing to do is to define the interface.  Here's one possibility,
> modeled after addBeforeCommitHook().  The major difference is that a
> true/false value is passed to the hook unconditionally, to tell the hook
> whether the commit attempt succeeded (true) or aborted (false):

right.

> 
> def addAfterCommitHook(hook, args=(), kws=None):
>     """Register a hook to call after a transaction commit attempt.
> 
>     The specified hook function will be called after the transaction
>     commit succeeds or aborts.  The first argument passed to the hook
>     is a Boolean value, true if the commit succeeded, or false if the
>     commit aborted.  `args` specifies additional positional, and `kws`
>     keyword, arguments to pass to the hook.  `args` is a sequence of
>     positional arguments to be passed, defaulting to an empty tuple
>     (only the true/false success argument is passed).  `kws` is a
>     dictionary of keyword argument names and values to be passed, or
>     the default None (no keyword arguments are passed).
> 
>     Multiple hooks can be registered and will be called in the order they
>     were registered (first registered, first called).  This method can
>     also be called from a hook:  an executing hook can register more
>     hooks.  Applications should take care to avoid creating infinite loops
>     by recursively registering hooks.
> 
>     Hooks are called only for a top-level commit.  A subtransaction
>     commit or savepoint creation does not call any hooks.  Calling a
>     hook "consumes" its registration:  hook registrations do not
>     persist across transactions.  If it's desired to call the same
>     hook on every transaction commit, then addAfterCommitHook() must be
>     called with that hook during every transaction; in such a case
>     consider registering a synchronizer object via a TransactionManager's
>     registerSynch() method instead.
>     """
> 

> Fuzzy:  what happens if an after-commit hook invokes addBeforeCommitHook()?
> I think it should be a (detected) error.  (The current transaction is
> winding down, and it's "too early" to try adding hooks to the next
> transaction -- it doesn't exist yet.)

When you mean "detected error" you mean an exception is raised or just
the error is caught and ignored within the internals ?

> 
> Fuzzy:  should after-commit hooks be called before or after the
> afterCompletion() methods of registered synchronizers?  The analogous
> question wrt before-commit hooks and beforeCompletion() methods was left
> unanswered, and I'm happy enough leaving it undefined here too.

Let's discuss and fix this in a second step for both before and after
commit hook system ?

	J.

- --
Julien Anguenot | Nuxeo R&D (Paris, France)
CPS Platform : http://www.cps-project.org
Zope3 / ECM   : http://www.z3lab.org
mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFDMdHPGhoG8MxZ/pIRAsZoAKCEzrvhzPDvdnk7febChAVnftpsEgCfebi1
QvQlBJKfFmGCxwHDDm6PbYM=
=Gu2L
-----END PGP SIGNATURE-----