RE: Idempotency in EPP

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> Can I just get confirmation of a small point regarding idempotency?
> 
> My understanding of idempotency is that if the server 
> received two identical
> commands from a registrar then it should produce the same 
> results for each
> identical command. This is to ensure, for example, that if 
> the server is
> hanging off a session-less protocol that cannot guarantee 
> unique delivery of
> datagrams it's OK to action the same command twice. There 
> seems to be two
> aspects to this - that both commands have the same effect, 
> and that both
> commands return the same results to the client.
> 
> First question: Is that a correct interpretation?

No, it's not.  Idempotency isn't about ensuring that you get the same
results for each command, it's about ensuring that the net effect on
something (an object in the case of EPP) is the same.  If you send two
identical <create> commands and the first one succeeds, the second one is
going to fail, and the net effect after each is that there is a domain
object in some identical state.

> So for example, if registrar X creates domain Y with an appropriate
> <domain:create> command and follows that with an identical 
> epp command, both
> commands have the same effect (either both succeed or both 
> fail) and with
> exactly the same result epp response.
> 
> Second question: Is that example correct?

Again, no.  If we assume that the first command succeeds, the second command
MUST fail because the domain object can't be created twice.

> If the above are true, it follows for example that the EPP 
> server needs to
> keep a certain degree of history. For example if registrar X 
> deletes domain
> Y, and actions the same command again, the server needs to 
> remember that
> domain Y used to belong to registrar X in order have the same 
> effect and
> return identical responses each time. This is not necessarily 
> a problem; we
> do that kind of thing anyway.
> 
> If all the above are correct interpretations of idempotency in EPP, it
> follows that it also applies to changing passwords, so for example if
> registrar X changes its password from Y to Z, the server 
> needs to store not
> only the current password but also the previous password for 
> each registrar.
> 
> Can someone confirm or deny this interpretation for me? Thanks.

Having to maintain some sort of history as you described above implies
maintaining state information at the transaction level, which can get ugly.
As things are now each command is atomic and isolated so the server can act
on each command independently.

There's a book titled "Transaction Processing: Concepts and Techniques" by
Jim Gray and Andreas Reuter, ISBN 1-55860-190-2 [1], that describes
idempotency in great detail.  Anyone writing a transaction processing server
really ought to consider this book to be required reading.

-Scott-

[1] Info from amazon.com (sorry if the URL gets broken across two lines):
http://www.amazon.com/exec/obidos/ASIN/1558601902/qid=1025189383/sr=2-1/ref=
sr_2_1/002-0024993-1270444