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

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

My comments inline...

-----Original Message-----
From: Andrew Wilkinson3 [mailto:awilkinson@uk.ibm.com] 
Sent: Tuesday, December 20, 2005 5:56 AM
To: Sazi Temel
Cc: Alastair Green; 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

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. 

Sazi: The participant will continue, ignore the prepare messages but
this will yield failure not success - see below.

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. 

Sazi>> +1

Assuming that the overall prepare vote was to commit this will allow the
transaction to complete successfully. 

Sazi: But participant by ignoring multiple prepare requests may let
coordinator to abort to transaction possibly because of timeout... Since
the prepare messages are ignored by the Participant - It only replies
once - unless the coordinator compares the Participants 'id' and decides
that the participant already responded/prepared, the transaction will
fail - which could be saved otherwise. If comparing the participant id
is needed for the coordinator to make right decision anyway, why would
one make this as early as possible? (P.S I am using the term id here
loosely, do not mean any particular form of id, since the discussion is
still continuing on that issue)

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].

Sazi>> +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. 

Sazi>> +1 another approach that would yield success may be the
participant, instead of ignoring the prepare messages, will send prepare
for all the prepare requests - that will yield a success since then the
coordinator has all the votes, but it would be a costly success in some
cases. 

However, given that we can achieve a consistent outcome without any such
mechanism I would question its worth. 

Sazi>> Whether it is failure or success, it is an outcome. However it
seems to me it is creating a failure when it could easily create a
success in some cases. 

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.

Sazi>> I agree with the general approach. However I don't see any more
forcing an implementer by this approach then by what is in the current
spec. 

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
>