Re: interposition

[Mark Little <mcl@arjuna.com>]

> I believe this should actually happen in reverse order. The
> sub-coordinator must assume that any of its participants (in local
> proximity, but likely in a separate server) are susceptible to failure,
> and as such as them to prepare all work before it performs any
> preparation on its side, returning a vote to the coordinator.

Did you miss a message exchange? We went through this on Wednesday/Thursday.

> Technically speaking, if the sub-coordinator fails, it will not be able
> to prepare itself or its participants and the transaction will timeuot
> and rollback by the coordinator. If a participant of the sub-coordinator
> fails, the sub-coordinator will still attempt to prepare before giving
> up. Hence, it should ask all its participants to prepare first, and once
> all votes have been tallied perform work on its side. It must, however,
> record such a tally in durable storage.

Agreed, and as was pointed out last week, the email was not meant as an
implementation document, simply as a statement of the work that must be
performed.


> Again, from the perspective of the user this is transparent. The Web
> service defines it's expected inputs and outputs, but not how it goes
> about doing its work. Indeed the initiator may not be aware of all
> participants indirectly used in the transaction (but will be aware of
> all participants directly used), and not be able to record them in the
> audit trail.
>
> The audit trail should only reflect the direct participants of the
> transaction, and will never be able to reflect all indirect
> participants, specifically where other protocols (or direct API calls)
> are being used.

I suspect you have missed a significant portion of this argument, that has
been going on via email and the teleconferences over the last 2 weeks.

Mark.

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