Re: interpretation of 'EPP idempotency'

[Klaus Malorny <Klaus.Malorny@knipp.de>]

"Hollenbeck, Scott" wrote:
> 

> >your solution surely works, but, from a design perspective, this is IMHO a
> bad
> >solution. Each request has to take care for itself not to violate the
> >idempotency constraint. E.g. the contact create command e.g. requires to
> >specify a <contact:id> to solve the idempotency problem, but the renew
> command
> >requires something quite different, namely the current expiration date,
> which
> >does not make any sense for the semantics of the command itself.
> 
> Creation and renewal are fundamentally different operations, even at the
> database level.  Both, however, involve comparing the current state of an
> object to the desired state of an object and then doing something if it's
> possible to produce the desired state.  Given that different attributes
> define the state of an object and the operations that may be performed on
> the object, I don't see the problem with commands requiring different
> attributes to perform the needed state comparison.  In the case of renewal
> you're moving the current expiration date into the future, changing the
> state of the object as a result of a successful operation.  Using this
> attribute as an indicator of the current state prior to attempting to
> produce a new state is reasonable.  Likewise, using a different attribute (a
> unique identifier) to determine if an object can be created is also
> reasonable.

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.

> 
> > [...]
> 
> I disagree.  If a client is unsure if any command was processed
> successfully, they can try it again.  Doing so is guaranteed to not have
> damaging results.  If they get back a "succeeded" response, they can update
> their own records and move on.  If they get back a "failed" response, they
> look into the third and fourth error code digits to determine the exact
> failure, and resynch/roll back/whatever accordingly.  If you're suggesting
> that a server shouldn't provide different types of error responses (and thus
> that a client shouldn't be expected to understand different failure modes),
> the alternative is to be more generic.  Software can be written to provide a
> layer of abstraction for a client that wants less detail, but at some point
> the detail needs to exist.
> 
> > [...]
>
> No, the responses are quite distinguishable.  In one case it may be
> "success", and in the other it may be "failure", and each is clearly
> identified by response code and a unique server-assigned transaction
> identifier.  This is as it should be because each response is tied directly
> to a very specific command, one of which succeeded and one of which failed.

There is a real misunderstanding here. Please see below.


> A good OLTP system should NOT provide a response to a command that describes
> the result of processing some other command.

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

> 
> > [...]

> The message received back shouldn't first be interpreted as "domain exists"
> in the case of a repeated domain create command failure -- the primary
> message is _"command failed"_, and the "domain exists" part is extra
> information that helps to explain why the command failed.  If the command
> fails, the client shouldn't create or keep it's own copy of the data.  If a
> response is lost, I think it's very reasonable for the client to issue a
> separate, atomic inquiry, and to ensure data consistency using the results
> of the query.  If they prefer to blindly repeat a command, that command MUST
> be treated as a distinct command in it's own right, it must succeed or fail
> in it's own right, and results reported must describe the success or failure
> of this isolated operation.  Doing otherwise is bad OLTP design.

In a single client model, i.e., a single client connects to the server, sends
commands and receives answers, this should work. But we have a lot of
registrars, and each registrar will maintain multiple connections to the
server. With the assumption that the clients of a single registrar work
independently, i.e., one client does not know what the other client does, your
model may fail. 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?

In the CORE SRS protocol, it is quite easy. Both clients submit a "status"
meta command with the client transaction ids of their create requests. This
command either tells them that their command has not been executed or returns
the results of their command. It neither violates the ACID properties you
mentioned. There is no requirement of deep analysis on the response behaviour
of the server on resubmitted commands.

> 
> >Instead of building upon idempotency constraints which affect the design of
> >each command, it would be better to have a separate layer that deals with
> >problems that appear in a client-server architecture. The way we do it in
> the
> >CORE SRS Protocol is one solution, it is quite simple and it works.
> 
> There's nothing stopping anyone from defining an additional processing layer
> to provide whatever feature you think is lacking.  Transport and security
> layers are already described, and folks are designing and implementing SDKs
> to provide additional abstract layers to deal with connection management,
> error handling, etc.

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

> 
> <Scott/>


regards,

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     Klaus.Malorny@knipp.de             Tel. +49 231 9703 0