Re: Command Recovery (was RE: interpretation of 'EPP idempotency')

[Dave Crocker <dcrocker@brandenburg.com>]

At 05:12 AM 9/19/2001, Hollenbeck, Scott wrote:
> >Well, a good OLTP system should also provide means for full recovery.
>
>No argument from me on that point.

As one would hope, the exchange on idempotency has been about "how", not 
"whether".

As I recall, Gray invented relational database methods, so a book on 
transaction processing, from him, ought to be more than adequate.

Given that:

1)      idempotency in transaction systems is something that has been 
around for a long time and is, presumably, well understood, and

2)      transaction systems are about exchanging things, just as protocols 
are about exchanging things, so the mechanisms for achieving idempotency 
should translate over to a protocol like EPP both easily and well.

therefore:

It should be straightforward to have EPP use a well-established technique 
from the transaction processing world, and the only debate should be about 
the tradeoffs among the well-established techniques for achieving idempotency.

Let me strongly encourage folks to cast the discussion strictly within that 
framework.

         -----

That was the primary point of this note.  Now...

Wandering into areas I know nothing about:

The protocol essences of indepotency would seem to be

a)      whether to add parameters, to achieve idempotency

         my own guess is that adding protocol features that are special for 
achieving idempotency is ok;

b)      whether to have special state changes.

         The latter means:  if an idempotent command previously succeeded 
at the server but is, for some reason, repeated by the client, should the 
server simply signal success or should it signal error.  Signalling success 
makes for a simpler state machine, since the client has no special 
processing to perform.  Hence the client would not be seeing, or 
participating in, "command recovery", but would merely be doing a command, 
the same as always.  The state machine in the server is essentially 
identical, except that rather than sending an error message it sends a success.

d/

----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464