Tim Peters wrote at 2005-9-22 15:23 -0400:
>>> 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).
>> 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
>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
>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).
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org