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

[Andrew Wilkinson3 <awilkinson@uk.ibm.com>]

Sazi,

In the case of coordinator-initiated completion, as in the example you 
cite below, the protocol can complete in success even in the event of the 
coordinator having multiple registrations for the same participant. The 
state tables in the AT spec dictate that should a participant recieve a 
prepare protocol message when it is already in preparing state then it 
should ignore the protocol message and simply continue with its completion 
processing. Assuming that the overall prepare vote was to commit this will 
allow the transaction to complete successfully. Having said that I do 
accept that point that, in the case of participant-initiated completion, 
not detecting duplicates can lead to the protocol completing in failure - 
i.e. a BA being compensated/cancelled as outlined in my earlier e-mail 
[1].

The question here is whether or not we should make any attempt to specify 
a mechanism by which we can avoid the mismatch in information regarding 
the coordinator and participant causing  "unnecessary" completion in 
failure - as you say the addition of participant identifiers to provide 
duplicate registration detection would be one such mechanism. However, 
given that we can achieve a consistent outcome without any such mechanism 
I would question its worth. I accept that there are advantages in that it 
can address some corner cases as described in Alastair's earlier mail [2] 
but it isn't necessary to produce an interoperable implementation that 
provides consistent outcomes, as such we shouldn't force an implementors 
hand by mandating anything in the specs.

Andy

[1] http://www.oasis-open.org/archives/ws-tx/200512/msg00198.html
[2] http://www.oasis-open.org/archives/ws-tx/200512/msg00202.html

"Sazi Temel" <sazi@bea.com> wrote on 19/12/2005 21:44:36:

> 
> Andrew,
> Yes the protocol will complete in both cases, even without a duplicate
> detection. However the question is not whether the protocol will
> complete or not but how could it complete without going through all the
> steps until the prepare phase. 
> 
> Here is a scenario where not detecting the duplicates will yield
> unnecessary work to reach an outcome (a failure):
> 
> P sends a REGISTER to C
> C registers P once, and sends a REGISTER RESPONSE to P (the message lost
> but C is not aware of it)
> P sends another REGISTER to C (for the same activity)
> C registers P second time and sends a REGISTER RESPONSE to P again (this
> time message reached to P but P is not aware of second registration, it
> thinks the first message is lost)
> 
> Now, C thinks there are two participants (and will prepare both) and P
> thinks it registered only once. So the outcome of this activity will be
> a failure. However this unnecessary failure could be avoided if the
> duplicate is detected earlier. 
> 
> I think the real cause of this failure is not because a duplicate is not
> detected but because both ends have wrong information about
> registration. In order to work efficiently both ends must have correct
> information. P must know how many times it is registered and C must know
> how many Ps are registered. Detecting the duplicates might be one way of
> going around - but there may be other ways too. I am not saying
> duplicates should not be allowed, but this info should be communicated
> back to other end (to P) and duplicate registration info closes the gap.
> 
> .Sazi
> 
> 
> -----Original Message-----
> From: Andrew Wilkinson3 [mailto:awilkinson@uk.ibm.com] 
> Sent: Monday, December 19, 2005 5:17 AM
> To: Alastair Green
> Cc: Ian Robinson; Mark Little; 'Max Feingold'; Peter Furniss;
> ws-tx@lists.oasis-open.org
> 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
>