[ZODB-Dev] afterCommitHook

[Dieter Maurer]

Tim Peters wrote at 2005-9-22 15:23 -0400:
>[Tim Peters]
>>> ...
>>> 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).
>
>[Dieter Maurer]
>> But it would give very strange semantics:
>>
>>   A transactions has something at its beginning, it knows nothing
>>   about -- and this is committed or aborted depending on the
>>   fate of this transaction.
>>
>>   Bound to result in big surprises...
>
>Yes, it's unattractive.  I have to say that "has something at its beginning"
>is too strong, the truth is more that it _may_ have something transactional
>at its beginning, depending entirely on what the after-commit hooks do.
>Non-transactional "something"s are irrelevant.

But "may have" is as bad as "has" (maybe even worse) from a semantics
point of view. A transaction (as seen by the user)
should start in a state it precisely knows -- i.e. no unknown lingering effects
from the past.

>Is the other way more attractive?  Running after-commit hooks "at the end"
>of the current transaction has the same kinds of problems:
>
>    Then a transaction may have something transactional at its end
>    that's silently ignored.

Then at least this transaction knows about the hook
because it (hopefully) registered it.

But, I agree: an "afterCommit" hook tells (by its name -- and
names are primary contract elements) that it runs after the commit.
Thus, the transaction is already committed. It must not have
fürther effects after the commit.

I think, we should run the "afterCommit" hook in its own transaction
(if we need an "afterCommit" at all) and maybe abort the transaction
automatically.

> ...
>There's no problem either way if users swear not to do "anything
>transactional" in after-commit hooks.  It's unattractive to leave that to
>good intentions and/or luck, and I don't see an easy way for either approach
>to _prevent_ "something transactional" from happening while an after-commit
>hook is running.

Thus, promiss the user that any persistent changes he may try
will be lost: Put the "afterCommit" in its own transaction and abort
it afterwards.

> ....
>I suppose a Transaction could abort() itself "just in case" after
>after-commit hooks ran.  Then transactional changes made by after-commit
>hooks would be (silently) lost -- but wouldn't screw up the next transaction
>(which would again start with a clean slate).

Good!

-- 
Dieter