too fast out-of-order messages

No optimization comes for free. Here is a problem with supporting
priority message processing in OPES. I am seeking the group opinion on
how the problem should be handled.

We want to allow out-of-order transaction-dependent messages to be
able to abort an in-progress transaction as fast as possible. This
optimization has a problem: it is possible that the "fast"
<xaction-end> message will be processed by the callout server _before_
the server processes the corresponding <xaction-start> message. If the
current protocol rules are followed, that fast <xaction-end> message
will be ignored because it will not match any known transaction.
Moreover, the transaction may not be terminated at all, until the
timeout happens (which is exactly the opposite of what we want!).

Possible sane solutions:

        0) Prohibit out-of-order messages and related
           optimizations.

        1) Prohibit out-of-order messages until the other
           side acknowledges that it received the
           <xaction-start> message (and, hence, the
           transaction is now known to that other side).
           The acknowledgment may be done explicitly
           by immediately sending an <i-am-here> message
           or implicitly by sending other transaction-dependent
           messages as a part of normal operation.
           We may even require immediate ACKs.

        2) Require <xaction-end> message to always be sent
           via the usual [slow] channel, even if another
           copy of the message was sent via a "fast" channel.
           This way, if fast message is too fast, we have
           no optimization but preserve the same semantics.
           Same carbon-copy rule can be applied to all
           future out-of-order messages. Note that it is
           OK to send two <xaction-end> messages because
           the second one will be ignored by the recipient.

Personally, I favor (2) because it allows for an optimization, is
simple, has no overheads for those that do not support the
optimization, and does not require creation of the "other side heard
us" state.

Note that we can inform implementors that they may _want_ to send
explicit ACKs as an optional feature (they are allowed to do that
already), especially if the callout server does not expect to send any
other transaction-dependent messages for some time. Again, the ACKs
should use existing <i-am-here> messages.

Comments/opinions?


Thanks,

Alex.