[DGD] Sequence guarantees among different execution rounds (was: Callout delays are now advisory)

[Shentino]

On Tue, Aug 31, 2010 at 2:46 AM, Shentino <shentino at gmail.com> wrote:

> Just had a little chat with felix on dgdhub, and found out that callouts
> with distinct delays of the same type, started from the same ER, are no
> longer guaranteed to execute in any order.
>
> Once a callout expires, it enters the pending cloud and can mingle with any
> other such callouts until it gets picked to fire.
>
> Apparently the change was made to enhance Hydra's parallelism.
>
> Just confirming this tidbit and making it public, since it apparently
> missed the Changelog.
>
>  The behavior in question being superceded is this:

https://mail.dworkin.nl/pipermail/dgd/2006-August/005224.html

Felix confirms at present the implementation still conforms, but this is
officially deprecated now, and it should be assumed that once a callout has
expired, it enters the pool of pending execution rounds and can be fired at
any time, and no assumptions should be made about sequence or ordering
versus any other callouts that are expired and pending execution.

In this respect, the only way to guarantee sequencing is to start the later
callout from the earlier callout.

Anyway, just to summarize my understanding of this, pending execution rounds
have only the following guarantees about ordering:

1.  Callouts aren't executable until their delays expire.

2.  A callout that expires and becomes executable can be executed at any
time.  Depending on system load, or conflicts with other execution rounds,
it can and may be delayed arbitrarily.

3.  Callout rounds, once they have expired, have no defined order,
regardless of when they were scheduled, which object they were associated
with, or what delays they were called with relative to those of other
callouts that may have been scheduled from the same round.

4.  I/O related execution rounds, triggered by network input, are serially
injected inside their connection.  Only one I/O round for a given connection
is outstanding at a time.  Such I/O round can be delayed arbitrarily just
like a callout round for reasons of data conflicts, rollbacks, or system
load.

5.  I/O rounds from different connections have no defined order.

6.  I/O rounds and callout rounds have no defined order.

I'm assuming felix will be happy to correct me if I messed up.