Re: [ws-tx-implement] scenario 5.2

[Alastair Green <alastair.green@choreology.com>]

Doug, I think you're right. This is the scenario that tests repeated Prepared, as opposed to Replay, as was.

Presumably PS1 and PS2 could collaborate privately to send PS1 Prepared1, PS2 Prepared 2, PS2 Prepared, rather than step 6 (PS1 sends Prepared, IA stops it getting to CS), running asynch with 7/8 (resend PS1/Prepared, send PS2 Prepared)?

The point is to achieve a CS input sequence PS1, PS1, PS2. (Strictly, ordering of PS1/2 and PS2/1 is irrelevant, so long as PS1/1 has preceded both of them.)
This scenario shows that repetition is the mother of reliability. It proves that PS1/Prepared, PS1/Prepared is functionally equivalent to PS1/Prepared, PS1/Replay.

Alastair

Doug Davis wrote:

"Peter Furniss" <peter.furniss@erebor.co.uk> wrote on 08/07/2006 06:47:47 PM:

> scenario 5.2 RetryPreparedCommit calls for two Participants, but the
> orchestration description doesn't match properly, and there seem to
> be some ambiguities in the message exchange.
>  
> what is the trigger for blocking ?

Isn't it the Prepared from PS1?

> from first or second Prepare sent
> out ?  What is the trigger for "recovery" = first or second Preparedreceived ?

Isn't it the 2nd Prepared from PS1? (After it recovers)
 
> There doesn't seem to be much point in the second participant, vis-
> a-vis the objective stated, so would it be better to revert this to
> one participant ?

PS2 is there to make sure the tx stays in Prepare state until PS1
recovers - that's why its Prepared messages are blocked until PS1
sends its Prepared after it recovers.  We're testing to make sure
the CS knows how to deal with duplicate Prepared (I think).

> (erebor/choreology and IBM interwork on this one, but it can be non-
> deterministic - the erebor/choreology orchestration reflects
> ambiguities in the description)

Not sure I see the non-deterministic part of it.

> Peter