From: leon breedt <bitserf@...>
Date: 2004-09-29T05:30:44+09:00
Subject: Re: safety of timeout()

Hi,

Thanks for the detailed elaborations, folks. Good to know I'm not
unique in finding this non-trivial to do as correctly as possible :)

On Wed, 29 Sep 2004 01:37:43 +0900, Paul Brannan <pbrannan@atdesk.com> wrote:
> I don't think sequencing messages is sufficient to solve the problem.
> A protocol like what you describe provides reliable messaging, but
> not much more.  For example, suppose I want to fail over to the backup
> system if I time out -- I can do this, but I run the risk of performing
> the operation more than once.  At that point it becomes a question of
> policy (can I afford to take that risk, or is that risk truly
> necessary?).
In my case, I'm lucky enough that each operation requires only one
message from the client to my server, so it becomes a matter of being
able to safely determine the identity of the request so that a
subsequent request with the same identity would be discarded.

In my case, both the primary and backup system would use the same
RDBMS data source to keep track of what's been processed.

This server exists purely to prevent the problem of clients
accidentally submitting the same request twice, in the realm of credit
card payments.

Determining the identity correctly to allow valid second attempts
through is interesting. At the moment, I use serial numbers as well,
but I'm not entirely happy with this, as there was no negotiation
process to obtain these.

I also provide the guarantee to the client app that as soon as I've
acknowledged a request, its been persisted, and the server will
attempt to process it until it gets a deterministic OK/FAILED result.

So if the client times out before receiving my acknowledgement, and
they resubmit, they'll receive the in-progress error, and can send a
query to determine the status.

Leon