On Wed, 26 Feb 2003, jfcm wrote:
At 22:29 26/02/03, Alex Rousskov wrote:
On Thu, 27 Feb 2003, jfcm wrote:
At 17:24 25/02/03, Alex Rousskov wrote:
<data-end xid amid [error] reason>
<message-end xid amid [error] reason>
<xaction-end xid [error] reason>
Why not also just?
<zap xid [error] reason>
What would be the meaning of the <zap> OPES message? The three old
messages above are based on three persistent "objects" or "states"
that OPES protocol has to maintain (data flow, application message, and
application transaction). See predraft for detailed definitions. What
does <zap> refer to? How is it different from, for example,
<xaction-end>?
<zap> as I say would be for the three of them altoegether. I want to
get rid of everything about that transaction. I do not want to
consider anything left which may be ressource consuming or unclean
anywhere.
This is exactly what <xaction-end xid error reason> does.
Well this will just introduce it :-). What I mean is that <zap> meaning
"to kill immediately whatever is related to the transaction", will also
kill whatever extension we may add in the future.
This is exactly what <xaction-end xid error reason> does.
I said "also". Instead of your three messages, one zapper.
<xaction-end> implies the other two, so only one message needs to be
sent, just like with <zap>. See examples in the predraft.
Let say that I call a web site through a translation OPES. If it is
too long to wait or if text comes by parts, I want to be able to
escape. This information is to hit the translation CPU asap. As a
translation operator I want to save every CPU time I can to provide
the fasted and smoothest service. And if it is paying not to be
cheated.
Looks like <xaction-end error> already supports this.
Also, the servers must know they face an emergency situation because
they may have to react differently from a normal termination. They
do not expect any emergency in a standard <xaction end>.
That is exactly what Oskar Batuner pointed out after predraft 00 was
released. The problem is now fixed -- a special "error" flag has been
added to distinguish normal termination from an abort/emergency.
<xaction-end error ...> is not a "normal" termination.
Do you agree that <xaction-end error> is equivalent to <zap>? Or is
there more functionality in <zap> that <xaction-end error> is missing?
Thank you,
Alex.