[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
Peter Furniss wrote: >>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. >> >> > >With no change to the current texts, I don't see how you can get >already-registered unless the coordinator does an illegal EPR >comparison. (that is really part of 014 - whatever we specify as the >reaction, there needs to be a sound way of detecting duplicates - no >change is not an option). > > I'm trying to consider the issues in isolation, but I'll admit that's difficult ;-) >But apart from that (i.e. assume we have a duplicate detection means), >and back to >the conceptual point of this issue, why specify that a coordinator >detecting that Register is for the same Participant as as one already >registered must fault with AlreadyRegistered ? Just assume that the >transport, or the sending implementation has caused the duplicate to >turn up, and reply with a RegisterResponse reflecting the Coordinator's >endpoint. > > My intention was to point out that a solution is possible within the scope of the current specification. Whether or not that solution is one we wish to adopt, is the subject of this and other discussions, just as the other proposed solutions have been. >In 95% of cases the EPR's will be unchanged. >If they have changed (which would only be because the endpoint owner >"wanted" to change it), the most recent SHOULD be used for sending by >the peer (not MUST because that would impose complications for some >persistence strategies). > > > > >>>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. >> >> > >Well, we closed a quarter of the issues list yesterday, and this one is >related to at least two of the others, and the discussion has made good >progress. I think it's a little early to >be worrying about timescales. > > > I disagree that it is too early. Several of the companies on this list have implementations that are already interoperable and, speaking as the representative of one of them, we'd like to get reduce the amount of time this TC takes to standardise. Mark.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]