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

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

>-----Original Message-----
>From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de]
>Sent: Wednesday, September 19, 2001 4:39 AM
>To: Hollenbeck, Scott
>Cc: ietf-provreg@cafax.se
>Subject: Re: interpretation of 'EPP idempotency'

>Yes, I do understand this. Nevertheless, to archive the idempotency
property,
>you add attributes to the commands that are not necessary. There is no
>technical requirement to supply a preset ID to the registry for creating a
new
>contact. There is no technical requirement to supply the old expiration
date
>to renew a domain.

The contact <create> command requires an ID so that the contact can be
uniquely identified, much like a domain or host name is used to uniquely
identify a domain or host.  The ID isn't preset, it's requested at <create>
time.

Earlier in this thread we heard about a problem that may arise when contacts
aren't identified by a unique key.  If you're suggesting that unique
identifiers/keys aren't needed to identify objects in a database, you've
lost me.

If you mean that the current expiration date doesn't need to be known to
renew a domain name, you're right.  However, not only does it help to make
the <renew> command idempotent, it helps to ensure that both client and
server have a consistent view of the object before and after processing the
command.  This isn't a bad thing.

>Well, a good OLTP system should also provide means for full recovery.

No argument from me on that point.

>Take the following example:
>
>It happens that a customer of registrars wants to register a domain.
>Unfortunately, he submits the domain twice. At the registrar, two different
>clients (in the view of the registry server) process these requests in
>parallel. Both send the corresponding domain create commands to the
registry.
>One of the commands succeeds, and the other fails, of course. But before
the
>responses are returned, a router in between crashes, killing the logical
>connections between the clients and the server.
>
>During recovery, whatever both clients will do, they both receive exactly
the
>same responses. They cannot determine whether their own request was
>successfully processed or not.
>
>Can you tell me what they should do in this situation?

Ahh, OK, I see your point here.  I see two ways we might be able to address
the issue:

1. Add a status command that checks to see if a particular client-provided
transaction identifier has been logged as part of a successful command.
With client TRIDs being OPTIONAL [1] this won't work if the client doesn't
provide a TRID, but it can help if they do.  Or,

2. Add client TRID information to the <info> response for an object.  If we
log the TRID of the last write operation (if one is provided), clients can
do an <info> command, look at the client TRID, see if it's one they
recognize, and react accordingly.

Is one preferable over the other?  I kind of like the second option because
it fits into what's documented right now.  Does anyone else have an opinion?

>Does software exist or is in development that deals with the problem we are
>discussing?

I'm not aware of anyone whose written anything to deal with the recovery
issue as you just described it, but I was specifically referring to software
that implements other service layers, like connection pooling or error
management.  I believe the Liberty RTK has features for both, and I know
that VeriSign is also writing such code.

<Scott/>

[1] Making client TRIDs OPTIONAL was discussed some time ago, and I don't
recall anyone objecting back then.  If anyone has an issue with it we really
ought to start a separate thread to reopen the issue.