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.
Wait a second, to avoid a misunderstanding. The example you are
describing is this really using a <xaction-end> message to abort? I
thought it should actually be a <producer-end amid reason> message
instead of <xaction-end xid reason> because other application
messages within this transaction are not affected, are they?
You may be right, depending on the application protocol and state. For
example, it makes no sense to continue processing an _uncachable_ HTTP
response if the client has left and the whole transaction (the HTTP
request-response pair) can be terminated. If response is cachable, it
may make sense to continue, especially if a large portion of the
response has been received already, and if the cache stores
post-processed responses.
[...]
It seems that I misunderstood the whole concept.
I thought a transaction could be more than a single request-response pair.
I thought when the OPES processor opens a transaction it tells the callout
server what to do with all following application messages, e.g.
<xaction-start "URL-classification for HTTP requests">
following hundreds of HTTP requests before the transaction stops.
That would have been a nice way to reduce the exchange of always the same
meta data.
Martin