[ZODB-Dev] afterCommitHook

[Julien Anguenot]

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

Sorry for de delay on this thread. Was busy with other stuffs...

Tim Peters wrote:
[...]
> It intensifies an issue only hinted at before:  non-transactional code in an
> after-commit hook is clearly no problem, but what about transactional code?
> "The next" Transaction object (for the transaction that will follow the
> current one in time) doesn't exist yet, and any interaction with the current
> Transaction object will be lost.  Trying to call addBeforeCommitHook()
> during an after-commit hook was mentioned before, but it's not the only
> fuzzy case.  What if, e.g., an after-commit hook modifies a persistent
> object?  Tries to do a commit() of its own?>
> before-commit hooks are less puzzling this way, because they clearly occur
> while the current transaction is still in mid-stream.
>
>

Then it should be the responsability of the devel to deal with his own
transaction commit within the afterCommitHook(), wouldn't it be ?

I mean, this is an *after* commit hook after all. If one wants to change
persistent objects then one can use the beforeCommmitHook() (with
ordering support right ;) ) to launch it at the end just before the
actual commit.

I see, on my side, the afterCommitHook system as a way to launch non
transactionnal code only. (AFAICS right now)

I've been thinking about lauching asynchronous code from there too
because usually they deal with the transactions themselves afterwards.
Here we are using zasync a lot and it could make sense launching the
zasync calls from there *after* the main transaction job's done. This is
still speculations at this stage right ;)

>>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.
> 
> 
> Cool again.  And that's a lot faster than I could make time to review it
> <wink>.
> 

ok then I'm in.

> 
>>>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 ?
> 
> 
> I mean that the interface defines it as an error, and that it's guaranteed
> an exception will be raised if it occurs.  Alas, if we view the after-commit
> hook as being called "in" the current transaction, there are mounds of
> things that should be considered errors (any transactional code).  OTOH, if
> we view the after-commit hook as running at the very start of "the next"
> transaction, the implementation becomes harder to picture (although the edge
> case semantics become clearer:  the after-commit hooks run "in" a
> well-defined transaction then).
> 

I like Dieter's proposal regarding this issue. (again sorry for missing
the discussion when it was hot)

> 
>>>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 ?
> 
> 
> Leaving something undefined doesn't necessarily mean it's broken.  It means
> instead that the implementation is free to do whatever it wishes, and code
> relying on undefined behavior is itself in error (although perhaps not a
> "detected error").  For example, it so happens that beforeCompletion()
> methods are called after before-commit hooks today.  Because the interface
> doesn't define the relative ordering of these things, that's fine.  The
> implementation tomorrow could do them in the other order.  If there isn't a
> _reason_ ("use case") to specify the order, it's good to leave it undefined
> (gives the implementation more freedom, spares writing mounds of tedious
> test code verifying artificial constraints nobody cares about, and spares
> burdening readers with mounds of tedious interface docs defining artificial
> constraints nobody cares about ;-)).
> 
> 

ok then ;)

Can I open a branch of off the trunk for the afterCommitHook() ?

Cheers,

	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

iD8DBQFDOHbbGhoG8MxZ/pIRAjDLAJwIphNhIokoRW0RKaDJYMiJSytMfgCfcVvT
MrvYWtU9YVqigvo56ufr+ks=
=f/y1
-----END PGP SIGNATURE-----