recovery and redirection followup

[Mark Little <mcl@arjuna.com>]

Given my earlier recovery and redirection email, I'd like to make the
following specific suggestions:

(i) that each entity address has the capability for being a compound
address, such that if the first entry in the address (call it the primary)
is non-responsive, subsequent entries may be sent the same message. If used
at the slightest failure indication then the user and system may fall into a
virtual-partition situation, whereby multiple active instances of an entity
(coordinator/participant) co-exist in the same environment; solving this
problem is not trivial, and relies upon replication techniques. However, the
following pragmatic approach could be taken: each entry in the compound
address could have a "use" criteria, such that, for example, entry 2 is only
used if n COMM_FAILURES are observed and entry 3 is used if m
TRANSIENT_FAILURES are observed. The probability of a virtual partition is
still non-zero, but it is up to the application/BTP implementer to
configure. And obviously an address need not be compound in the first place.

(ii) there is no implicit assumption that the end-points of each part of a
composite address are identical. The primary may well be a coordinator, for
example, whereas a backup may be a redirecor that uses a UDDI service to
locate an alternate (recovered) coordinator.

(iii) a REDIRECT (or REPLACE/SUBSTITUTE) message that contains two fields
exists. The first field is the original (compound or uni-) address, and the
second field is a compound name. When received, an entity replaces all
instances of the original address with the new address. Obviously this
raises some (more) interesting security situations for us to consider in the
long term! This message can be sent at any time, including during the normal
execution of a BTP.

(iv) the REPLACE (or whatever) message has an acknowledgement possibility,
such that a recipient can indicate to the sender that it has received and
processed the message, and the sender can tidy up an logs. Obviously this is
optional, and need not be used for all redirections.

If we agree on something along these lines then it would be useful to put
examples of coordinator and participant recovery into the final document to
illustrate its use.

Mark.

----------------------------------------------
Dr. Mark Little (mark@arjuna.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203