[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
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]