Re: interposition requirements

I 
  agree with most of the mail and as long as we can agree that the subcordinator 
  has the ability to either propagate its own coordinator, and thus hide the 
  subsequent invocations, or the root then I think this gives the most 
  flexibility. 

As I said in one of the emails, if the application 
wants to allow this then there's nothing we should do to prevent 
it.

  
I 
  agree with your comments on performance with regard to the intranet example 
  but in a private trusted federation of services then registration back to the 
  root from all participants in the chain is appropriate, and even registration 
  to a separate transaction coordination service for the federation of services. 
  

Agreed, but I think that this scenario is not the 
majority use-case. Even in trusted intranets I know of, there are various 
levels of trust, and registering all participants with the root coordinator 
won't be allowed.

  
It 
  also means that performance is better and the latency that will be evident in 
  "walking the tree" will avoid the possibility of failure scenarios corrupting 
  the coordination of the termination.

Having interposition cannot currupt data integrity. It 
introduces another failure point, but typically the interposed coordinator is a 
(or hosts a) full participant in the termination protocol anyway, so its failure 
will affect the outcome one way or another.

 

Mark.

 

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