[ZODB-Dev] afterCommitHook

[Tim Peters]

[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 ;-)