RE: [ZODB-Dev] afterCommitHook
[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
Re: [ZODB-Dev] afterCommitHook
Victor Safronovich wrote: Hello Chris Withers, Friday, September 23, 2005, 9:12:19 PM, you wrote: CW Why not just use MaildropHost? 1. Because it is *nix only, it use os.fork(), using Thread.setDaemon(1) is more friendly for me. I KNOW Jens will accept good patches ;-) 2. Because it takes all his options from Config file, not Zodb objects. ...maybe even for this. 3. Because there is imposible to import mainloop from Products.MaildropHost.maildrop.maildrop, because Products.MaildropHost.maildrop is not package. huh? 4. Because mainloop is the huge function, MainLoop class with small methods is more friendly for me, to subclassing from it. again, I'm sure patches would be accepted... This topic is not a zodb-dev problem and should be moved to zope-dev. ...or likely [EMAIL PROTECTED] Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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
Re: [ZODB-Dev] afterCommitHook
-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 RD (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- ___ 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
