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

[Doug Davis <dug@us.ibm.com>]

sorry I didn't notice this earlier but
there's one bit that worries me, in scenario 5.2, Ian wrote:

   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

Its the "PS2 sends D2PC:Prepared to CS"
that might be an issue.  In the other scenarios, I think, we tried
to limit our tweaking of implementations such that a smart guy in the middle
could drop messages and give us the odd behavior we wanted.  The text
above however seems to imply that PS2 holds off sending its Prepared until
after PS1 recovers and resends its Prepared.  That's a bit different
for us.  To be honest I'm not sure if its a problem for us (or anyone)
but I wanted people to notice it.

I'm wondering if we can get the same results by having
the CS (or I guess IA) drop the Prepare messages going to PS2 until the
CS gets the 2nd Prepared from PS1?

thanks,
-Doug

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

06/28/2006 01:17 PM

To	"Ian Robinson" <ian_robinson@uk.ibm.com>
cc	Doug Davis/Raleigh/IBM@IBMUS, <ws-tx@lists.oasis-open.org>
Subject	RE: [ws-tx] Interop scenario doc - scenario 5.1

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