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

["Sazi Temel" <sazi@bea.com>]

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