OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


Interesting one.
 
In the case of CONFIRM_TRANSACTION, (ii) would clearly be wrong, as it would be changing the confirm-set, with potentially horrible application effects. In fact, I don't think anything except (i) is sound for confirming a Cohesion - if the application thinks there are inferiors that don't actually exist, was it relying on the work it thought they had done to make its choice ?  Since the confirm decision must be logged before issuing any confirms, this isn't that onerous on the implementation, perhaps.

With PREPARE_INFERIORS it's less important, because the initiative passes back to the application anyway.

But allowing a list of invalid ids in the FAULT, rather than just one would seem to be useful anyway. But even one means there is a bug in the application program (we hope, as btp implementors :-)

I think I incline to just specify:

 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

That leaves some flexibility to the implementor - especially it *can* bail out early if it wants to. Different implementations might give different answers, but only to a bugged application.

On "walking down the list" - we don't think we currently say that the ordering of the inferiors in the list is significant, though an implementation would obviously be likely iterate in practice. But there is certainly no expectation (and it may be highly undesirable) that it would go through the list synchronously,

I know there's no upper limit, but 1000 Inferiors sounds rather a lot :-)

Peter. 

 

BTP Issue 99 : PREPARE_INFERIORS and FAULT(InvalidInferior)

Category: minor technical
Submitter: Mark Little, HP
Description:
When calling PREPARE_INFERIORS (CONFIRM_TRANSACTION), a list of inferior ids is supplied. Now, if any of these inferiors is invalid, the spec. currently says that the InvalidInferior FAULT is generated. However, that's all it says. This leaves it open to implementation specific interpretation (the list below is not meant to be complete):

(i) I could check all inferiors prior to issuing prepare on any of them and only go ahead if all ids in the list are valid.

(ii) I could simply walk down the list and issue prepare and stop when I get to an invalid id. However, what happens to the inferiors I haven't talked to yet and what do I do with those I have.

(iii) I walk down the list and issue prepare and remember if I see any invalid id. At the end of the list I return the appropriate FAULT.

(iv) modify the status-item field such that it is possible to identify which id was invalid.

Now I have a preference as to which I think we should do, but the real reason for this message is to try to get some agreement on a standard approach that we can put in the specification. (BTW, I think (iv) would be a useful enhancement anyway - if I send a list of 1000 inferior ids and only one of them was invalid it would be good if I could get that id (or list thereof) back on the fault message.)




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC