[Julien Anguenot] > ... > 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 understand that using this for non-transactional code is the _intent_. I nevertheless want the implementation to be robust against violations of that intent, in part because it's so very easy to modify a persistent object "by accident". People will do it, and I don't want apparently insane behavior as a result. I'm reminded that it was always thought to be insane to close a connection without first aborting or committing changes to objects modified in the connection, but for many years ZODB did nothing to detect such insanity. When Zope fell by accident into doing exactly that, horrible widespread problems resulted. With benefit of hindsight, it would have been incomparably cheaper to engineer-in current ZODBs' ConnectionStateError from the start. Running after-commit hooks in their own transaction seems a sane way to prevent the worst consequences of abuse. It also raises other questions. One that's been asked here is whether this new transaction can be explicitly committed by the user. Any way of answering that raises more questions in turn, like: - If not, now can an attempt to commit it be caught as an error? - If so, what happens if after-commit hook A does transaction.commit() but there are more after-commit hooks to run after A? That is, which transaction do _they_ run in? The transaction that installed A is gone, and the transaction A was running in has, by hypothesis, also been committed. - Either way: - If an after-commit hook A adds a before-commit hook, is that added to the transaction A is running in; ignored; or an error? In some sense "the natural" answer is that before-commit hooks added by A will be added to the transaction A is running in. - If an after-commit hook adds an after-commit hook, ditto? Note that the sample interface docs we started with _claim_ they'll run too, but the transaction that installed A no longer exists if A is running in a different transaction. "An after-commit hook added by A will be added to the transaction A is running in" again seems the most natural answer. > 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 ;) Yup. > ... > Can I open a branch of off the trunk for the afterCommitHook() ? You can always open a branch! Hope you weren't waiting for approval on that -- opening a branch is harmless. Whether a given branch ever gets merged to the trunk is a different question ;-) _______________________________________________ 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