RE: [bt-spec] BTP Issue 99 : PREPARE_INFERIORS andFAULT(InvalidInferior)

[Peter Furniss <peter.furniss@choreology.com>]

I was about to put in a proposed solution on this one, then though I'd chase it round one more time.

 

We are agreed that an invalid id causes a FAULT for PREPARE_INFERIORS and CONFIRM_TRANSACTION.

We are agreed that no confirmation should occur if it is CONFIRM_TRANSACTION.

 

 

new -  we need to add CANCEL_INFERIORS to the consideration.

 

Mark proposed for uniformity we should not allow any action (send PREPARE, send CANCEL) if *any* of the inferior ids are wrong.

 

That's basically reasonable, but there is no need to impose it on all implmentations. For safety, in the confirm case, the implementation must check before it confirms, but there is no similar requirement in the other cases. In fact, the other two are really just packaging of "prepare-one-inferior" and "cancel-one-inferior" allowing multiple targets. But CONFIRM_TRANSACTION is different, as it defines a new set of inferiors that must confirm together or not at all.  An implementation could choose to implement the prepare and cancel as strictly sequential, just working through the list. This won't work for confrim, whcih must check they are prepared first.

 

So I'd like to suggest as I did before.

 

Peter 

 

 -----Original Message-----
From: Mark Little [mailto:mark_little@hp.com]
Sent: 22 January 2002 10:26
To: Peter Furniss; BTP
Subject: Fw: [bt-spec] BTP Issue 99 : PREPARE_INFERIORS and FAULT(InvalidInferior)

 

----- Original Message -----

From: Mark Little

To: Peter Furniss ; bt-spec@lists.oasis-open.org

Sent: Tuesday, January 22, 2002 10:21 AM

Subject: Re: [bt-spec] BTP Issue 99 : PREPARE_INFERIORS and FAULT(InvalidInferior)

I would agree that (i) is the only implementation that we should allow. I'd go further and say that for uniformity it should be the case for PREPARE_INFERIORS and CONFIRM_INFERIORS, but we could always discuss this.

 the status-item field is a list

  if there is more than one invalid id, the Decider returns at lest one in the FAULT, and may return more

  if it is CONFIRM_TRANSACTION, no CONFIRMs shall be issued if any of the ids are invalid

Mark.

 

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250