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

["Ram Jeyaraman" <Ram.Jeyaraman@microsoft.com>]

Ian,

The suggested changes look fine.

If there are no further comments, I will go ahead and make the changes
to the interop document. Thanks.

-----Original Message-----
From: Ian Robinson [mailto:ian_robinson@uk.ibm.com] 
Sent: Wednesday, June 28, 2006 7:40 AM
To: Ram Jeyaraman
Cc: Doug Davis; ws-tx@lists.oasis-open.org
Subject: RE: [ws-tx] Interop scenario doc - scenario 5.1

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