On Thu, 27 Feb 2003, Oskar Batuner wrote:
We want to allow out-of-order transaction-dependent messages to be
able to abort an in-progress transaction as fast as possible.
There always may be a need to abort a transaction in progress,
by why "out-of-order" and why "as fast as possible"?
... because some may want this optimization.
For example, consider this situation: Callout server processing of
each response chunk is long and "expensive". The callout server is
processing the first chunk, and 9 next chunks are still in its TCP
buffers waiting to be parsed and processed. The user aborts its
request. There is no reason for the callout server to continue, but it
will not know until it gets a <xaction-end> message. Without the
optimization in question, the callout server will not know until all
10 chunks are processed.
Please note that I am just explaining the motivation, not arguing
whether this optimization is worth supporting.
I'd strongly suggest to avoid (to prohibit) cross-channel messages.
All transaction processing should be done within the channel where
it has started. Some kind of <transaction-abort> message may come at
any moment as one side of transaction gets an abnormal condition
that makes further processing unnecessary. But there is no "urgency"
in transaction termination - just no need to continue.
There is no semantics urgency indeed. It is a performance
optimization. See above for a typical example.
I can propose two type of scenarios: A. callout processor gets
unrecoverable error condition (type 500) in situation when OPES
processor keeps a copy of initial message waiting for the next
more-data request. B. Data consumer unexpectedly closes connection
to the OPES server while request processing is in process. In
both cases other side of transaction does not expect transaction-end
message - this is why I propose to have a special message that
can appear at any moment (related to protocol state machine).
Yes, your examples are valid. We already agreed to add the "abort"
mechanism. The only question is whether it makes sense to allow the
abort to happen faster, as a performance/resource optimization.
But there is no need to expedite transaction termination, this
is just a way out of intermediate processing status.
Can you propose scenarios where out-of-band message
gives significant advantages?
Yes, see my example above. A general optimization area is "slow and
expensive processing of data chunks for messages with multiple
chunks". Is this area large enough to be worth caring for?
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.
I support your choice (2), even in more strict definition:
all transaction processing goes through the same channel on
which it was started.
That is option, (0) actually. No optimization (see below).
(0) is not an option: there always are situations when regular
processing can not be continued, so there should be some way out.
Another terminology conflict! By out-of-order I mean out-of-SENT-order
not out-of-semantics-order: the message that was sent later was
received first. As agreed, <xaction-end error> can be sent at any time
and is never out of semantics order (i.e., you can stop at any time,
just like you wanted).
(1) can not happen if everything goes on the same channel (in fact
it is a good illustration what kind of problems may be created by
asynchronous multi-channel processing).
Exactly. We need to decide whether the associated problems are worth
the optimization benefit. BTW, if you can think of any other problems,
please let me know. Keep in mind that only messages that can be sent
at any time (like your abort message) will be allowed on priority
channels if multi-channel support is added. We are not talking about
sending data out of order, for example.
b) reuse of a message in a different sematic context is
usually a very bad thing.
I agree, but the semantic context here is the same: "I am here,
processing xid".
In this situation it is very easy to misinterpret keep-alive message
as a confirmation (well, you may introduce transaction id in
keep-alive, but IMHO this creates even more mess).
Actually, predraft-01 does have xids and even amids in <i-am-here>
messages :-). I do not see how they can hurt, and I can give examples
where they help (you may want to abort an application message due to a
timeout but still be able to finish the corresponding transaction
involving the other 9 messages; that is, you may want to be more
specific). But this is not related to the primary question of this
thread:
Should we allow fast abort optimization?
If yes, how to make it safe?
Your last comments make the questions broader:
Should we allow multi-channel transaction processing?
If yes, should we allow fast abort optimization?
If yes, how to make it safe?
Thank you,
Alex.