RE: [ws-tx] Interop scenario doc - scenario 5.1

[Ian Robinson <ian_robinson@uk.ibm.com>]

The need for the 2nd resource - discussed at the Dublin F2F - was for the
scenario "RetryPreparedCommit" (was scenario 5.3 before the F2F; currently
scenario 5.2). The purpose of the 2nd resource was to allow the 1st
resource to send a duplicate 2PC:Prepared before the 1st resource sent its
2PC:Prepared (thus forcing the Coordinator to consume a 2nd 2PC:Prepared
while in PreparedSucess state). At present this scenario says that the
first 2PC:Prepared message should not be delivered to CS but this does not
then accomplish the goal of tesing the CS behaviour (state=PreparedSucces;
msg=2PC:Prepared). I believe we need to modify this scenario to be closer
to the intent discussed at the F2F. That intent was for the participant to
fail/recover while in PreparedSuccess state.

I think this scenario should actually be:
   CS sends Durable2PC::Prepare to PS1
   CS sends Durable2PC::Prepare to PS2
   PS1 sends Durable2PC::Prepared to CS
   (PS1 fails and recovers)
   PS1 sends Durable2PC::Prepared to CS   // Retry!
   PS2 sends Durable2PC::Prepared to CS
   CS sends Durable2PC:Commit to PS1
   PS1 sends Durable2PC::Committed to CS
   CS sends Durable2PC::Commit to PS2
   PS2 sends Durable2PC::Committed to CS



For the "ReplayCommit" scenario (5.1) mentioned by Doug below, I don't
think we need the 2nd resource that has been added and agree we could
remove PS1.
This scenario would then be:
   CS sends Durable2PC::Prepare to PS
   PS sends Durable2PC::Prepared to CS
   CS sends Durable2PC::Commit to PS
   (PS suffers from internal failure)
   (PA prevents any resent Commit from reaching PS - simulating failure)
   Upon recovery, PS sends 2PC::Prepared to CS
   CS re-sends Durable2PC::Commit to PS
   PS2 sends Durable2PC::Committed to CS


   The text "(CS commits the transaction)" is not really meaningful in this
      scenario.


The distinction between these 2 scenarios is the state that CS is in when
it receives 2PC:Prepared. In "ReplayCommit" (scenario 5.1) the CS is in
state Committing; in "RetryPreparedCommit" (scenario 5.2) it is in state
PreparedSuccess.

The other 5.x scenarios look fine.

Ian




                                                                           
             "Ram Jeyaraman"                                               
             <Ram.Jeyaraman@mi                                             
             crosoft.com>                                               To 
                                       "Doug Davis" <dug@us.ibm.com>,      
             28/06/2006 01:23          <ws-tx@lists.oasis-open.org>        
                                                                        cc 
                                                                           
                                                                   Subject 
                                       RE: [ws-tx] Interop scenario doc -  
                                       scenario 5.1                        
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Doug,

The changes you note below seems quite reasonable and correct.

If there are no objections, I will update the scenarios doc to reflect the
changes below.

On why PS1 is used: During the last F2F one of the members mentioned that
there be at least 2 participants in this scenario.

Thank you.

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Tuesday, June 27, 2006 2:05 PM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] Interop scenario doc - scenario 5.1


For scenario 5.1 ReplayCommit it current shows this flow:


Initialization


IA sends an application message tns:ReplayCommit request to PA containing
CoordinationContext.
PA registers PS1 and PS2 with CS for a Durable2PC protocol.
PA responds with an application reply tns:Response.


Message Exchange


        (IA initiates Commit)
   1. CS sends Durable2PC::Prepare to PS1
   2. PS1 sends Durable2PC::Prepared to CS
   3. CS sends Durable2PC::Prepare to PS2
   4. PS2 sends Durable2PC::Prepared to CS
   5. CS sends Durable2PC:Commit to PS1
   6. PS1 sends Durable2PC::Committed to CS
   7. CS sends Durable2PC::Commit to PS2
      (CS commits the transaction. PS2 suffers from internal failure)
   8. Upon recovery, PS2 sends 2PC::Prepared to CS
   9. CS re-sends Durable2PC::Commit to PS2
   10.      PS2 sends Durable2PC::Committed to CS

I believe this is wrong.
1 - The "(CS commits the transaction)" should come after step 10 - meaning
the Coordinator should not exit the "Committing" stage until it receives
Committed from all of the participants
2 - Something should block resent "Commit" messages from the Coordinator
(if any) until PS2 has a chance to resend its "Prepared" message - since
the point of the test is how the Coordinator deals with extra Prepared
messages while in the Committing stage.

Not sure who has the pen but i think we should update the doc to correct
this - something like:
   1. CS sends Durable2PC::Prepare to PS1
   2. PS1 sends Durable2PC::Prepared to CS
   3. CS sends Durable2PC::Prepare to PS2
   4. PS2 sends Durable2PC::Prepared to CS
   5. CS sends Durable2PC:Commit to PS1
   6. PS1 sends Durable2PC::Committed to CS
   7. CS sends Durable2PC::Commit to PS2
      (PS2 suffers from internal failure)
      (PA prevents any resent Commit from reaching PS2 - simulating
      failure)
   8. Upon recovery, PS2 sends 2PC::Prepared to CS
   9. CS re-sends Durable2PC::Commit to PS2
   10.      PS2 sends Durable2PC::Committed to CS
      (CS commits the transaction)

Not sure what the purpose of PS1 is (and would prefer to remove it) but oh
well  :-)

thanks
-Doug