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 _______________________________________________ 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
