Participant timeouts

[Peter Furniss <peter.furniss@choreology.com>]

One of the agenda items for tomorrow is "participant timeouts". This is a
short summary of the question - my thoughts, after discussion with Alastair
but not necessarily remembering everything we thought.


First, a couple of things this issue is NOT about:

a) client-initiated, advisory timeouts.

Some of the classic transaction api's / protocols have a timeout parameter,
usually on the begin or equivalent.  If you consider what it does, this is
primarily concerned with the client:coordinator relationship - it advises
the coordinator that if, for whatever reason, the client hasn't requested
commit by time T, then it isn't going to; and consequently the coordinator
can reasonably initiate rollback at that time. Of course, the coordinator
has the authority to initiate rollback at any time, so its only advisory.

Such a timeout could be propagated to subordinates (participants), but it is
less clear what they should do with it. What is certain is that, once they
have voted to commit (sent ready, sent prepared), they cannot use the
timeout. Up until then, if they reach the timeout without receiving a
prepare, they could decide to rollback locally, and remember to vote
rollback when asked - but again the subordinate has the authority to do that
at any time prior to voting commit.  In the BTP case, where (for some
scenarios)

It is not proposed that this client, advisory timeout need be in the
standard BTP messages or context

b) client-initiated, timescale

The first (uncirculated) draft of the message set had a "timescale" field in
the context. This wasn't the timeout as above, but intended as an advice to
the service/participant of how long the business transaction was expected to
take. This was intended to allow an implementation that supported, say, both
a locking and compensation approach to cancel to decide which one to use.

This is a fairly low probability requirement, and shouldn't be in the
standard protocol.

Now what it is about:

The business requirement of the service may be such that it will impose time
limits on how long it will remain undecided. This is commonly the case with
reservations - "your tentative booking is held for 24 hours, but if not
confirmed before then, it will be offered to others". The default operation
on the timeout may be confirm or cancel (hotel bookings that will charge you
if you don't arrive and don't cancel are real-world equivalent). And the
action on the timeout may be certain (the financial instrument offers valid
for 30 seconds WILL expire) or just a possible (the restaurant won't delete
your unconfirmed booking unless someone else wants it)

This is identified in the requirements document as
Requirement #6: Positive/negative action timeout
Requirement #7: Positive/negative operation timeout

The working assumption has been that the timeout and the default would be
qualifiers on the ready vote.


Some of the questions:

Should there be a required confirmation round of prepares that don't have
the timeout allowed:   But why should the participant agree to this when it
couldn't agree (for sound internal business reasons) before. I

Should there be an optional repeat prepare/vote - with the participant able
to give a different answer.
Should the participant be able to vote cancel whereas before it voted ready.
This would be a way to find out if a cancel really had been applied. Less
clear how to cope with the case where the participant confirmed by default.

Got to catch a plane !

Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX