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

Ian’s suggested text (practically) assumes that if a Participant does not receive a RegisterResponse message it should assume that it is registered successfully... If this is not so, the Participant may try Register again which is allowed. However, the participant really intended to register only once but was not sure whether registration worked or not! It cannot assume it is registered - what if message did not reach the coordinator at all? Now if the Participant is one that cannot handle multiple registrations (unless it is required by the protocol) it has no option but wait so that the lost message to arrive/recovered or just end the participation into this transaction. Even if the completion protocol handles this situation in the state table, I assume it will not be a successful end.

I have to check the state table for this to see how it is handled... For now, it seems to me that the participant should be allowed to register multiple times as if it is registering once (i.e., Coordinator detects the duplicate registrations, does not create a fault but sends an appropriate message in RegistrationResponse) which is possible using a Participant identifier as suggested by Alastair. Also by using different participant identifiers a Participant can register multiple times for any reason if it wants to do so. This will also eliminate unnecessary work that a Coordinator and Participant will handle because of the duplicate registrations (Coordinator will think there are multiple Participants and the Participant will handle multiple registrations instead of one)

,Sazi

From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Thursday, December 15, 2005 9:28 AM
To: Ian Robinson
Cc: ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable

Ian,

I don't think it's that straightforward. To start with my conclusion: having a participant identifier makes a lot of things easy (including the BA MixedOutcome case), with minimal change (add Participant identifier to Register). All other routes become more complex, both in spec and in implementation.

The accompanying Word document contains four diagrams which recapitulate the scenario in issue 014, and show a couple of solutions. One is the logical outcome, I think, of your suggestion, but it does not do a full job. The second illustrates the Participant identifier fix.

In addition, there are two related problems which we needn't have, if we use a Participant identifier on Register.

1) We can't do "checking from above". It is efficient, and simple, to observe the pool of registered participants to figure out if we are ready to initiate 2PC processing, or if we are ready (in the WS-BA Participant Completion case) to move on to phase 2 (Close or Compensate). We have found this capability very useful in a number of applications. It avoids application-level request/response counting. There are some applications where this is no need for an application response. It also avoids waiting for an application-level response (which generally equates to having a prepared/completed participant) before the fundamental checking precondition ("the minimum pool of registered participants is in place") is satisfied. Checking from above, in its simplest form, requires the ability to count. You could argue that n+1 is as good as n for that purpose, but that way lies confused application programmers. Plus, sometimes you need to know who, not just how many.

2) We still haven't solved the participant identification problem for the purposes of selective outcome (as per the latter half of the description in 014.

So, I think we kill three birds with one stone, if we adopt Participant Identifier on Register.

Incidentally, I think my revised wording for the proposed solution to 007 is wrong in the following respect. Peter has convinced me that it is pointless to return a fault in the event of out-of-order registration (one whose reception by the RS postdates the reception of a coordination protocol message by the Coordinator).

Alastair

Now, this is OK as long as we

If an initial Register attempt is accepted by the Coordinator, but the RegisterResponse is lost, then C believes it knows of a P (has an EPR for the P).

If a second Register now arrives (retry by P) the Coordinator has no option (given that EPRs are incomparable) but to treat the second Register as independent. It now has "two" participants.

If the registrant has failed and recovered then it will be able to associate its original EPR with its new EPR, and it can then use the C EPR given in the RegisterResponse to deliver coordination protocol messages in reply to messages sent to the original EPR, to that C EPR.

Ian Robinson wrote:

Regarding WS-RM, the "scope of work" section of the charter states:

"As general principles, these protocols ... must not depend on the

availability of reliable message delivery mechanisms outside of these

specifications."

This issue proposes a change to the semantic of the Register request but I

believe that none is needed. Retrying a Register request because of network

failures is not the only scenario in which a Participant can be registered

multiple times for the same transaction. The important consideration is

whether or not the multiple participant instances will behave properly when

they are directed to complete according to the specific agreement protocol

(e.g. AT or BA). And the state tables ensure that they can.

If the TC believes clarification is required then I would suggest the

following text:

A Coordinator is not required to detect duplicate Register messages, but

MAY attempt to do so by means that are out of the scope of this

specifiction. A registration requester MAY send multiple Register messages

to a Coordinator that does not detect duplicates - for example because it

retried a Register request following a lost RegisterResponse. If a

registration requester registers multiple times for the same activity then

the registered Participants MUST be prepared to handle multiple protocol

messages from a Coordinator that treats the multiple Register requests as

distinct Participants. There are a number of simple strategies for

accomplishing this. For example, the registration requester can generate a

unique ReferenceParameter for each Participant EPR that is passed in a

Register request.

Regards,

Ian Robinson

STSM, WebSphere Messaging and Transactions Architect

IBM Hursley Lab, UK

ian_robinson@uk.ibm.com

             Alastair Green

             <alastair.green@c

             horeology.com>                                             To

                                       Doug Davis <dug@us.ibm.com>

             13/12/2005 17:19                                           cc

                                       ws-tx@lists.oasis-open.org

                                                                   Subject

                                       Re: [ws-tx] Issue 007 - WS-C: Make

                                       Register/RegisterResponse retriable

+1.

Either we do it at the coord protocol level, or we start to mandate

something like WS-RM, which I would not favour, and would create some

pretty major ripple effects in specs and implementations.

Alastair

Doug Davis wrote:

      And what is that transport mechanism?  By default neither WSA nor

      SOAP will do

      retries.

      -Doug

 Kevin Conner

 <Kevin.Conner@jboss.co

m>

To

                                     Doug Davis/Raleigh/IBM@IBMUS

 12/13/2005 04:31 AM                                                    cc

                                     Christopher B

                                     Ferris/Waltham/IBM@IBMUS, Mark Little

                                     <mark.little@arjuna.com>,

                                     ws-tx@lists.oasis-open.org

                                                                   Subject

                                     Re: [ws-tx] Issue 007 - WS-C: Make

                                     Register/RegisterResponse retriable

      Doug Davis wrote:

      > One thing that concerns me about using the wsa:MessagID is the

      assumption

      > that you'll use the same messageID on each retry.  Can the Tx spec

      really

      > require this?  Other specs (like WSA) which are infrastructural can

      > probably make

      > this kind of requirement (if they need to), but I always viewed Tx

as

      > sitting on top

      > of these infrastructural layers and not so much as being part of

      them.

      > Implementations

      > will vary on this view but I wouldn't think Tx would want to

      mandate this

      > kind of choice.

      > thanks,

      > -Doug

      This really came out of the description of the original problem.  A

      request/response conversations was initiated and the initiator

      crashed

      before receiving the response.  The replay of a message at this

      level,

      especially as we are using WS-Addressing, would surely become the

      domain

      of a reliable transport.  My suggestion was therefore to defer this

to

      the transport mechanism to replay the conversations and not the

      higher

      level protocols.

Kev

ws-tx message