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

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

OK, now I understand ;-)

But we're going to have to persist something however we do it if we're 
to tolerate crash failures. If we went with the re-registration 
(replaceParticipant suggestion) then a participant-side implementation 
is going to have to persist the EPR it used for registration if it later 
wants to try to replace it. Of course we could simply consider that to 
be an implementation detail.

Mark.


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.
>
>
> Apologies, I didn't explain myself properly.  I was talking about the 
> different solutions (not scenarios) used for handling crash failures 
> and not transient failures.
>
> One solution requires the participant EPR being persisted with the 
> message ID whereas the other requires the participant EPR being 
> persisted with the participant id.
>
> The second may not necessitate storage of the participant EPR though 
> as an implementation could regenerate it from the participant id.
>
>     Kev
>