[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
The trouble is that the protocols won't work if Register is delivered more than once and not recognised as a duplicate. "won't work" = an undetected duplicate will either cause the transaction to rollback/ cancel or requires substantial additional specification (and implementation) to sort things out. The point that forces rollback is that it is NOT sufficient of the participant to accept multiple messages - it must SEND to the multiple endpoints at the coordinator that the multiple receipt of Register will have caused. How do you think it is going to do that, when it never received the RegisterResponse that contained the coordinator EPR for the first registration ? Since the coordinator will now see a registered participant that won't go Prepared (or equivalent), it will trigger rollback (on timeout or whatever) A) Do we agree this describes the inevitable behaviour, or have I missed something ? B) If the above is correct, do we believe such a rollback (or cancellation, or whatever) is desirable for all protocols (or indeed, any) ? For OTS, the presence of a forgotten registration would eventually cause the transaction to rollback, which was fine because the "principal of vulnerability" applied. (lost communications prior to commit decision were expected to cause rollback) For some WS-C-using protocols, "vulnerability" is explicitly contrary to the requirements (ws-ba) and is not required or, as far as I can see useful, for any (due to the different mapping to connection). If the coordinator won't detect duplicates, and the vulnerability is inappropriate, the protocol will have to repeat the EPR in some later message to the participant (retrying much of the semantic of RegisterResponse, in fact). For protocols like WS-AT and WS-BA-coordinator-completion, this could be handled with a rule about using the ReplyTo on the Prepare or Complete. For protocols like WS-BA-participant-completion, it is impossible - it would require another message - which would mean it was in fact coordinator-completion. C) Do we wish to make rules about using the EPR from ReplyTo on the C->P message, and ignore the EPR on the RegisterResponse, for ALL protocols (and disallow protocols whose first message is P->C, such as WS-BA participant-completion) ? The only other ways out I can see are: D) Register MUST only be sent once for each Participant AND the mapping to transport must ensure that Register is only deivered once. E) There is a participant identifier on Register and coordinators ARE expected to identify duplicates. Peter > -----Original Message----- > From: Ian Robinson [mailto:ian_robinson@uk.ibm.com] > Sent: 16 December 2005 11:34 > To: Mark Little; Peter Furniss > Cc: 'Max Feingold'; ws-tx@lists.oasis-open.org > Subject: Re: [ws-tx] Issue 007 - WS-C: Make > Register/RegisterResponse retriable > > > > > > > This topic is not unique to WS-C or indeed to connectionless > transports. In the CORBA Transaction and Activity services > the requester is responsible for either ensuring it registers > only once for a single set of protocol messages. While the > conection-based CORBA architecture eliminated the concern > over retrying the equivalent Register operations, there have > always been other "duplicate" registration scenarios in which > an application may forget its registration for one reason or > another and register a second time (the so-called "amnesia" > scenario). OTS has no normative statement about applications > registering multiple times although it places no burden on > the Coordinator to detect this primarily because, just like > with EPRs, there is no simple client-side (coordinator-side) > mechanism for comparing IORs. The Activity service went > further than OTS and made the explicit statement that > multiple registrations result in multiple sets of protocols > messages (section 2.2.5, add_action). This latter approach is > also assumed by the WS-Tx specifications today. To reiterate > earlier comments ([1], [2]) I recommend we resolve this issue > by making an explicit statement that Coordinator > implementations are not required to detect duplicate Register > messages. [1] proposes some precise text. > > [1] > http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archi ves/200512/msg00163.html > [2] > http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archi ves/200512/msg00176.html > > Regards, > Ian Robinson > STSM, WebSphere Messaging and Transactions Architect > IBM Hursley Lab, UK > ian_robinson@uk.ibm.com > > > > > Mark Little > > <mark.little@jbos > > s.com> > To > Peter Furniss > > 16/12/2005 04:12 > <peter.furniss@choreology.com> > > cc > "'Max Feingold'" > > > <max.feingold@microsoft.com>, > > ws-tx@lists.oasis-open.org > > Subject > Re: [ws-tx] Issue 007 > - WS-C: Make > > Register/RegisterResponse retriable > > > > > > > > > > > > > > > > > > > Peter Furniss wrote: > > >I think we may need to go back to the original, > architectural question > >here, then revisit the possible mechanisms once we've decided what > >should be. > > > >The original question is really in the issue title - phrasing it as a > >question: > > > > should the Register/RegisterResponse exchange be > retriable > > ? > > > >That is to say, should it be possible to resend Register on > behalf of a > >particular Participant (that is a single state entity > responsible for > >some part of the work of a transaction) if the > RegisterResponse is not > >received, with the eventual result being the same [for some sense of > >"same"] as if the original RegisterResponse had been received. > > > >A key element of that is that we are discussing the > registration of a > >single participant state entity, and not cases where a service > >deliberately wishes to register multiple participants. > > > >The possibility of a retriable register has scarcely come up > in earlier > >protocols because they mostly assumed a connection-based carrier or > >transport, and were expected to abort a transaction if the > connection > >failed before the commit decision. (I believe all of LU 6.2 > SYNCPT, OSI > >CCR/TP, OTS, TIP, OLEtx are expected to be "vulnerable" to > connection > >failure - I'm open to correction on some of those). > > > > > +1 > > >A feature of being connection-based is that it can be > assumed a comms > >failure on one side will be (sooner or later) reflected as a > failure on > >the other side. Thus if register (or equivalent) is sent to a > >coordinator and no reply comes back there is no point in > >sending another one - either the first one got there, and > the reply will > >come back, or the connection broke and that is sufficient to > cause the > >transaction to be aborted anyway. > > > > > Well there are always exceptions. For example, TRANSIENT in > CORBA sys-exs could be used to retry later. However, I agree > with the general point you're making. > > >But the WS-Tx family aren't connection-based in the same way. WS-AT > >explicitly states (ws-at, line 454) that different > connections are used > >for messages in each direction. So there isn't a single > connection that > >everything can pass on, and indeed every message could pass on a > >different connection. (further, given the generality of SOAP > mappings, > >there is no reason to assume that a connection failure is even > >detectable by the sender, though in the case of http it > would be). The > >WS-BA case is even stronger, albeit not in normative text > (ws-ba, lines > >34-40). > > > > > +1 > > >Now you *could* perhaps make a WS-AT implementation that was > vulnerable > >to connection failure, though I'm not sure it gives any > simplification > >in the implementation. Interoperation requires that you can > cope with > >new incoming connections, and ignore the closing of old > ones. You could > >monitor your own outbound connections and treat an unintended > >disconnect as a reason to abort (if you are still allowed to, of > >course) but it would seem to be perverse. (I think the only > >circumstance in which this is allowed is if coordinator sees a comms > >failure after sending Prepare - all other messages after the > >registration are either recoverable or part of aborting > >anyway) > > > > > >It is against this background that we should consider whether WS-C > >should make Register/RegisterResponse retriable. To say that it > >shouldn't would seem to be deliberatly importing connection-failure > >vulnerability to an environment where > >it is no longer needed. > > > >Of course, that's not to say a WS-AT participant-side would > be required > >to resend Register if it doesn't get a RegisterResponse back (on a > >different connection) or doesn't see an http 200 on the outbound > >connection. It is impossible to require self-initiated > behaviour of a > >non-persisted entity (because it can just say "oh, I crashed, didn't > >you notice ?"). > > > >------------------------ > >So, back to mechanisms. Can we make Register retriable at reasonable > >cost ? > > > >I have yet to see any argument against putting a participant > identifier > >on the Register. Although the coordinator is not allowed > test EPRs for > >equality, the participant must always be able to extract and combine > >various fields that will make an unambiguous identifier (it can do it > >other ways too, but the > >EPR must always contain at least sufficient - the problem > that disallows > >others to test is that it may contain other stuff) > > > > > A failure to receive a register response could trigger a > completely new register message with a new EPR (on the > assumption a retry of the first attempt caused the > already-registered fault to be returned). The only problem I > can see at present with this mechanism is that manufacturing > a new EPR for the "same" participant may not be feasible in > some environments. However, that could be seen as an > implementation problem. The advantage would be that no > changes to the specification are required > - other than a clarification of the text to call out this possibility. > > >The alternative of trying to make multiple registrations for > what is in > >fact the same participant work would seem to cause considerable > >complications. For atomic > >cases, the coordinator may not mind - it just sees two (or more) > >registrations and they must both be committed (or > rolledback). But Max's > > > > > > > >>"The participant > >> > >> > >>>simply needs to behave correctly[1] by distinguishing its multiple > >>>enlistments. > >>> > >>> > > > >is very questionable, because it will receive two Prepare's > (say), both > >delivered to the same EPR, but must reply to different coordinator > >endpoints, one given on > >the succesful RegisterResponse, one on the lost one. As in Alastair's > >diagrams sent earlier today, it would have to use the > Reply-To EPR (in > >which case, why not use that anyway and get rid of the > RegisterResponse > >altogether) [this is completely impossible for coordination protocols > >where the first message is participant to coordinator - see > Alastair's > >diagram 3] > > > > > I agree all of this is possible and may be sub-optimal in > certain degenerate situations. However, when weighed against > the timeline imposed for getting WS-C through to > standardisation, it may be that the "do nothing" approach I > mentioned above is the best option. > > >Gosh, this has ended up rather long (and will probably now > cross with > >other messages saying the same thing or rendering it out of date) > > > > > To be honest I don't have a hard stance on any solutions to > this issue at the moment. My only concern is time spent so > far and the fact that there are other issues to work through > that may be equally, or more, contentious. I hope we can > bring this to a conclusion (a vote) soon. > > Mark. > > >Peter > > > > > > > >>-----Original Message----- > >>From: Mark Little [mailto:mark.little@jboss.com] > >>Sent: 15 December 2005 16:50 > >>To: Max Feingold > >>Cc: ws-tx@lists.oasis-open.org > >>Subject: Re: [ws-tx] Issue 007 - WS-C: Make > Register/RegisterResponse > >>retriable > >> > >> > >> > >> > >>Colleen Evans wrote: > >> > >> > >> > >>>Forwarding for Max. > >>>Colleen > >>> > >>>-----Original Message----- > >>>From: Max Feingold > >>>Sent: Wednesday, December 14, 2005 6:22 PM > >>>To: ws-tx@lists.oasis-open.org > >>>Subject: RE: [ws-tx] Issue 007 - WS-C: Make > Register/RegisterResponse > >>> > >>> > > > > > > > >>>retriable > >>> > >>>After digesting this week's discussion on this topic, I have a few > >>>observations: > >>> > >>>- I cannot think of a protocol that requires idempotent > >>> > >>> > >>registration. > >> > >> > >>>WS-AT certainly does not need it. A conformant WS-AT > >>> > >>> > >>participant might > >> > >> > >>>only send a single Register message and report failure to the > >>>registrant if a timeout or comms failure occurs. It can also send > >>>multiple Register messages. The coordinator will create a new > >>>participant enlistment for each Register it receives. The > >>> > >>> > >>participant > >> > >> > >>>simply needs to behave correctly[1] by distinguishing its multiple > >>>enlistments. > >>> > >>> > >>> > >>> > >>You're right. OTS, for example, doesn't place a restriction on > >>participant registration either. Speaking purely about > transactions, > >>with the exception of the Activity Service, I'm not sure of > a protocol > >>that prevents multiple registrations. If we say that the > >>operation isn't > >>idempotent, then we definitely need to remove the fault > >>message though, > >>in case retransmissions are attempted for failure situations. > >> > >> > >> > >>>- One can imagine that different coordination types might have > >>>different expectations for what it means to send multiple > >>> > >>> > >>(duplicate) > >> > >> > >>>Register messages. Given that Register is scoped to a specific > >>>coordination type at both the participant and the > coordinator, it is > >>>not clear that the semantics of Register can (or should) be > >>> > >>> > >>universally > >> > >> > >>>constrained to a single pattern. > >>> > >>> > >>> > >>> > >>I'm happy to punt this up to referencing specifications. > >> > >> > >> > >>>- A hypothetical coordination protocol that wants to detect > >>> > >>> > >>duplicates > >> > >> > >>>should not overload existing WS-Addressing mechanisms. > Instead, it > >>>should use WS-C extensibility to create specific participant > >>>identifiers. Some protocols may need this functionality for > >>>correctness. I do not believe that any of the WS-Tx > >>> > >>> > >>protocols need it. > >> > >> > >>> > >>> > >>> > >>> > >>If we don't try to detect duplicate enlistments at this > level, then we > >>also get round the need for EPR comparisons and don't need to > >>add a new > >>participant URI to register either. > >> > >>Mark. > >> > >> > >> > >>>... > >>> > >>>[1] "Correctly" here means not splitting the transaction > >>> > >>> > >>tree. I can > >> > >> > >>>follow up on this if people are interested in the details. > >>> > >>>-----Original Message----- > >>>From: Peter Furniss [mailto:peter.furniss@choreology.com] > >>>Sent: Friday, December 09, 2005 9:54 AM > >>>To: ws-tx@lists.oasis-open.org > >>>Subject: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse > >>>retriable > >>> > >>>This is hereby declared to be ws-tx Issue 007. > >>> > >>>Please follow-up to this message or ensure the subject line starts > >>>Issue 007 - (ignoring Re:, [ws-tx] etc) > >>> > >>>The Related Issues list has been updated to show the issue numbers. > >>> > >>>Issue name -- WS-C: Make Register/RegisterResponse retriable > >>> > >>>Owner: Alastair Green [mailto:alastair.green@choreology.com] > >>> > >>>Target document and draft: > >>> > >>>Protocol: Coord > >>> > >>>Artifact: spec > >>> > >>>Draft: Coord spec working draft uploaded 2005-12-02 > >>> > >>>Link to the document referenced: > >>> > >>>http://www.oasis-open.org/committees/download.php/15738/WS-Co > >>> > >>> > >ordination > > > > > >>>- > >>>2005-11-22.pdf > >>> > >>>Section and PDF line number: > >>> > >>>WS-Coordination spec, Section 3.2 "Registration Service" l. 294 > >>> > >>> > >>>Issue type: Design > >>> > >>> > >>>Related issues: > >>> > >>>Issue 008 - WS-C: Remove fault 4.6 AlreadyRegistered > >>>Issue 014 - WS-C: EPR equality comparison is problematic > Issue 009 - > >>> > >>> > > > > > > > >>>WS-C/WS-AT: Is request-reply MEP useful? > >>> > >>> > >>>Issue Description: > >>> > >>>Register/RegisterResponse should be retriable exchange > >>> > >>> > >>>Issue Details: > >>> > >>>[This issue stems from Choreology Contribution issue TX-20.] > >>> > >>>Section 9 of WS-AT defines the WS-Coordination exchanges > >>> > >>> CreateCoordinationContext/CreateCoordinationContextResponse > >>> Register/RegisterResponse > >>> > >>>as request-reply exchanges. > >>> > >>>(Whether this request reply MEP should be used at all in the WS-TX > >>>specs is addressed in a separate issue: see "Issue 009 - > >>> > >>> > >>WS-C/WS-AT: > >> > >> > >>>Is request-reply MEP > >>>useful?".) > >>> > >>>Substantively, it may be particularly misleading to think of the > >>>Register/RegisterResponse exchange as a request-reply pattern. The > >>>implication of using this pattern is that there is a simple one > >>>message in, one message out exchange. The presence of a fault > >>>(AlreadyRegistered) as a potential response to Register > hardens that > >>>implication. > >>> > >>>Current behaviour would lead to service being informed it > >>> > >>> > >>has already > >> > >> > >>>registered a Participant, when it has in fact simply succeeded in > >>>registering a Participant. Superficially, the > AlreadyRegistered fault > >>> > >>> > > > > > > > >>>could simply be viewed as being unnecessarily verbose: the > reaction > >>>of the > >>> > >>> > >>service to > >> > >> > >>>the fault at run-time must be to treat > >>>it as uninteresting, i.e. as equal in effect to a successful > >>>registration. > >>> > >>>In fact there is a deeper problem. Consider the following scenario: > >>> > >>>A Coordination Service (CS) creates a Coordinator (C) for a > >>> > >>> > >>new atomic > >> > >> > >>>transaction (AT), and emits a CoordinationContext (CC). > >>> > >>>The CC is transmitted to an application service (AS). AS > (logically) > >>>creates a P which sends Register (R) to the Registration > Service (RS) > >>>EPR for AT, embedding the EPR for receipt of protocol messages > >>>outbound from C to P (CP EPR). > >>> > >>>The RS, on receiving Register, creates an EPR for inbound protocol > >>>messages from P to C (PC EPR), and embeds this in the > >>> > >>> > >>RegisterResponse > >> > >> > >>>(RR), which it sends to P. > >>> > >>>AS and P crash before the RR message is received by P, or the RR > >>>message drops and is never received by P. Either way, AS (on > >>> > >>> > >>recovery, > >> > >> > >>>or after > >>>waiting) causes P to > >>>resends R to RS. RS examines the inbound Register, > >>>and determines that it has come from a known P (see "Related > >>> > >>> > >>Issues", > >> > >> > >>>"WS-C: EPR equality comparison should > >>>not be relied upon"), i.e. that it is a duplicate registration. > >>> > >>>Currently, RS replies with an AlreadyRegistered fault, sent > >>> > >>> > >>to P. P now > >> > >> > >>>knows that he is registered with C, but has never received > >>> > >>> > >>the PC EPR > >> > >> > >>>(/RegisterResponse/CoordinationProtocolService element). > Any further > >>>retries of P send R to C will result in the same situation. > >>> > >>>C will never be able to receive messages from P. P will > never become > >>>Prepared. The transaction will eventually collapse through timeout. > >>> > >>>Therefore, the Register/RegisterResponse exchange must tolerate > >>>duplicates. If a Register message is delivered more than > once (either > >>>by the transport, or through comms-failure- or > >>> > >>> > >>recovery-induced retry) > >> > >> > >>>then the Registration Service should respond on each > occasion with a > >>>RegisterResponse containing the same PC EPR, to ensure reliable > >>>completion of the EPR exchange that permits the subsequent > >>>coordination protocol to operate correctly. > >>> > >>>NOTE. > >>> > >>>This change brings the R/RR exchange in line with the > >>> > >>> > >>behaviour of the > >> > >> > >>>CreateCoordinationContext/...Response > >>>exchange. There is a difference. R/RR is likely to be > >>> > >>> > >>implemented as a > >> > >> > >>>true idempotent operation. CCC/CCCR is > >>>not: each CCCR embeds a new RS EPR, and a new /Context/Identifier. > >>>But each exchange can be harmlessly replayed indefinitely, in the > >>>event of failure to receive the response message. > >>> > >>> > >>>Proposed Resolution: > >>> > >>>Insert the following text in WS-Coordination spec, Section 3.2 > >>>"Registration Service" immediately following current l. 294 > >>> > >>>"[New paragraph]The requester MAY send a Register message > for a given > >>> > >>> > > > > > > > >>>Participant more than once, and the underlying transport > >>> > >>> > >>could deliver > >> > >> > >>>the Register message more than once. > >>>On receipt of a Register message for a > >>>given Participant, which has already been processed > succesfully, the > >>>Registration Service MUST send to the requester a RegisterResponse > >>>containing the same CoordinationProtocolService element (Endpoint > >>>Reference for Participant to Coordinator protocol messages) as that > >>>contained in all > >>>previous RegisterResponses generated by > >>>the Registration Service which relate to the Participant's > >>> > >>> > >>request to > >> > >> > >>>register for this activity. > >>>[New paragraph]" > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]