Re: interposition

[Mark Little <mcl@arjuna.com>]

"If you send two messages with the same context to the same service then why would you expect to get two enlistments? There's been an implicit assumption on my part that a service will only register a single participant for each transaction. Are you saying this is not the case?"

This is interesting, and perhaps relates to a note in Pal's write-up of the conclusions from the Boston F2F.

I certainly do not believe that you should impose a one service-one participant restriction as a _general_ rule. A service (however delimited) is always free to offer a single point of coordination for a given business transaction, if it wants to. Other configurations may be desired or negotiated. The protocol should allow them to be implemented, unless forced to forbid them by some overriding functional need (which I see no sign of in this case).

<stuff deleted>

 

OK, I see what you meant, and I agree that we shouldn't limit the participation to one per transaction. However, we'd better make it clear in the protocol document what this means to an implementer, e.g., if they get it wrong and register (essentially) the same participant twice then it's going to get two sets of prepare/commit/rollback messages, and it had better figure out how to deal with them consistently. If we do that then I've no problem with this at all.

 

All the best,

 

Mark.

 

-----------------------------------------------------------------------
SENDER : Dr. Mark Little, Architect (Transactions), HP Arjuna Labs
PHONE  : +44 191 206 4538, FAX : +44 207 670 1964
EMAIL  : mark@arjuna.com