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

[Mark Little <mark.little@jboss.com>]

Kevin Conner wrote:

> Mark Little wrote:
>
>> crash failures: wsa:MessageID won't work unless we mandate that 
>> implementations persist their message structures, which isn't a good 
>> idea IMO. Adding a unique participant identification to the 
>> registration message, as Peter suggests in a different issue, would 
>> solve this, but there are other solutions too. The advantage of 
>> Peter's option is that it may be needed to resolve another issue.
>
>
> In either scenario we need to persist something.

Not true if we're talking about wsa:MessageID. As long as the algorithm 
used doesn't repeat id's, then a volatile memory is sufficient to 
tolerate transient failures such as message loss and retransmission.

>
>> In general, all of our messages are going to have to cope with 
>> transient failures. So I'd prefer to use wsa:MessageID across the 
>> board for that.
>
>
> +1 of course the definition of a transient failure changes with the 
> MEP in use.
>
>> For crash failures, at least in this case, I'd like to suggest we 
>> take a look at what we did in WS-CAF with the WS-Coordination 
>> Framework specification. There's a recoverParticipant operation that 
>> essentially lets you replace one registered EPR with another EPR and 
>> returns the protocol-specific EPR that you'd get from register. I 
>> think if we're going to tolerate crash failures, and by that I mean 
>> try to prevent them from aborting/cancelling inflight transactions 
>> unnecessarily, we need such a mechanism in general. Of course that 
>> could be the scope of a different issue, but I'd rather not solve the 
>> crash failure case here in an ad hoc manner if we agree that it's 
>> something we need to solve more generally.
>
>
> At least with having a second register message we could differentiate 
> between the regegistration of a crashed participant or a clash in 
> identifier generation.

+1

Mark.

>
>     Kev
>