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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-tx message

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


Subject: Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable


Alastair,
 
> So, introducing participant identifiers will resolve both Issue 007 
> and Issue 014. 
> 
> It is a more elegant approach that does not create forced 
> implementation choices that are required to work around its absence 
> for the duplicate registration problem. It is the only solution that
> will make BA MixedOutcome or BA Participant Completion registration 
> workable (at least, the only one thus far proposed).

I believe that it is possible to create an interoperable implementation of 
BA Participant Completion without being able to detect duplicate 
registrations. In the event of a coordinator receiving two register 
messages for the same participant, either because the register was retried 
or the transport delivered the message twice, it will expect the receipt 
of two completed messages. Should one of these messages not be forthcoming 
the coordinator may opt to complete in failure - sending cancel to the 
participant from which it has not received a completed message and 
compensate to the one from which such a message has been received.

Assuming that the participant implementation has been coded such that it 
does not retry sending of a register message (and we could mandate this in 
the spec if needed) what we're coping with here is an error in the 
transport and, as such, completing in failure is entirely appropriate. 
What's important is that the outcome is consistent and I believe that the 
BA state table ensures that this will be the case.

Andy


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