[ZODB-Dev] Re: Ordering before commit hooks

[Florent Guillaume]

Just back from vacation...


Jeremy Hylton wrote:
> On 8/22/05, Tim Peters <tim at zope.com> wrote:
> 
>>Jim still wonders, and he got me wondering too, whether the `order=` gimmick
>>is really needed.  For example, you could have gotten to the same end here
>>with the old method, by registering your actions with an object of your own
>>creation, and registering just one commit hook with the transaction, where
>>that one hook looked at the actions you registered with your own object and
>>ran them in whatever order _it_ determined was best.  The ordering logic
>>would have been out of ZODB then, not limited to what an integer `order` can
>>express, and might even benefit from "ah, if I have to run A, then there's
>>no need to also run B or C" kinds of optimizations.

But that only works if you have all the code in a single framework. If Zope 
had a commit hook, and that CPS wanted to add another one that "ran after 
Zope's", there would be no way to do it.

> I think that's the right reasoning.  I agree with Jim.
> 
> The transaction manager coordinates the actions of unconnected
> resource managers.  If there are several transaction participants that
> are all part of the same software package, they can provide their own
> internal ordering as you suggest.  If they are not related, then
> there's no reason to think they care about their order relative to
> other participants they know nothing about.  To the extent that
> software cares about order, there is likely a simple partial order
> (run before X) rather than the total order that order= suggests to me.

Yes I agree but the partial order makes the implementation much more complex 
than a global agreed-on integer scale (you have to deal with the naming of 
packages, potential loops, etc). I agree though that there has to be some 
"rough consensus" on what integer mean what (i.e., well-known values for 
important frameworks).

>>I'm inclined to agree with Jim that `order=` wasn't needed; that it was too
>>general for the specific use case we've seen; and that it's not general
>>enough for plausible other use cases.

I don't agree. To me this is an instance of the very general problem of 
ordering of subscribers (and indeed if ZODB depended on an event system this 
kind of thing would be done with an event subscriber). And we know very well 
that we have unresolved issues with the ordering of event subscribers, where 
the "order" argument would at least introduces some flexibility that we 
don't have today.

I vote for keeping it in ZODB 3.5

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com