RE: [business-transaction] PREPARE_INFERIORS

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

Since this is an ambiguity, with interoperation implications, (and I can't
see another issue to merge it into), I have added it to the issue list, even
though the list is closed for technical changes.

BTW, I think I've only ever said verbally the categorisation I've used for
the issues. Roughly:

technical : a question of what the specification should mean/what the
protocol should do and/or with substantial implications on implementation

minor technical: has implications on implementation, in some smallish area,
but no change to the general intent and purpose of the protocol

editorial: does not affect implementation, but does make changes in what the
spec tries to say

minor editorial: only changes details of what the spec says, without
changing what it meant to say

But if the submitter claimed a higher status, I used that even if I didn't
think it was. In other cases it really a judgement call.

The list is closed for new technical issues. I've been trying to avoid
getting to issue 100, but there are bound to be editorials, so we're going
to go over, aren't we.

Peter


> -----Original Message-----
> From: Mark Little [mailto:mark_little@hp.com]
> Sent: 21 January 2002 18:42
> To: BTP; Peter Furniss
> Subject: [business-transaction] PREPARE_INFERIORS
>
>
> 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.)
>
> Mark.
>
> ----------------------------------------------
> Dr. Mark Little, Distinguished Engineer,
> Transactions Architect, HP Arjuna Labs
> Email: mark_little@hp.com
> Phone: +44 191 2606216
> Fax  : +44 191 2606250
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>