interposition

[Mark Little <mcl@arjuna.com>]

Hopefully this is all implicit in what everyone's assuming, but to try to clarify what I mean by interposition and participation.

 

We all seem to be agreed that a participant takes part in the termination protocol. However, a participant can't simply do sub-coordination: that's different functionality. For example, a book purchasing participant can't suddenly decide to sub-coordinate on behalf of other participants it may talk to. The functionality required for sub-coordination is different from "straight forward" participation. A sub-coordinator needs to be a proxy for the coordinator, and this has implications on recovery and its interface (e.g., it now has to have the enlist etc. interface, which a "normal" participant doesn't need to have), as well as context propagation.

 

Therefore, being a subcoordinator is:

 

(i) a conscious choice of the implementer to provide that kind of functionality.

 

(ii) a conscious choice of the application/participant to use that functionality.

 

If a participant has the sub-coordinator interface and functionality then you can (essentially) flick a switch and enable/disable that functionality. However, if it doesn't then you can't. I am in no way saying that BTP should mandate that all participants should be able to behave as subcoordinators. It's a choice, and we should allow it. My original email of days ago was produced because it appeared as though we were mandating the opposite, i.e., that no participant could behave as a subcoordinator, and all participants, whether directly or indirectly communicated with, had to register with the root (and only) coordinator.

 

Mark.

 

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