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

["Peter Furniss" <peter.furniss@choreology.com>]

Reply to Mark,

Snipping the copy of my long bit on ws-tx not being connection-based
(thanks for the +1's Mark, and yes, there are edge cases where the older
specs would allow different behaviour)

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

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

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. 

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.


Peter