Web Services Atomic Transaction Interop Scenarios - Simple Failure Model

[Sanjaya Amarasekera <cr...@yahoo.com>]

Hi, 
              I have couple of doubts regarding  Scenario #5.1. ReplayCommit Of  Web Services Atomic Transaction Interop Scenarios (WS-AT Interop Scenarios) 1.1 - Working Draft 04, June 29, 2006
   
  1. Scenario #5.1. ReplayCommit.
   
              The message exchange for the scenario is described as follows 
   
  414 (IA initiates Commit) 
  415 1. CS sends Durable2PC::Prepare to PS 
  416 2. PS sends Durable2PC::Prepared to CS 
  417 3. CS sends Durable2PC::Commit to PS 
  418 (PS suffers from internal failure) 
  419 (PA prevents any re-sent Commit from reaching PS) 
  420 4. Upon recovery, PS sends 2PC::Prepared to CS 
  421 5. CS re-sends Durable2PC::Commit to PS 
  422 6. PS sends Durable2PC::Committed to CS  
   
              After Recovering from the internal failure, PS send  2PC::Prepared to PS.
   
  But according to  Web Services Atomic Transaction (WS-AtomicTransaction) 1.1 -  Committee Draft 01, March 15, 2006 “Replay” Message is described as follow under   2PC Diagram and Notifications ( line 221)
   
  Replay : Upon receipt of this notification, the coordinator may assume the participant has suffered a recoverable failure. It should resend the last appropriate protocol notification.
   
  Above description implies that upon recovery a Participant should sent “Replay” to the Coordinator and the Coordinator will re-send the last message
   
  This leads to a contradiction. Shouldn’t the messages exchange for the scenario changed as follows? Otherwise, for what does “Replay” message is used?
   
   (IA initiates Commit) 
   1. CS sends Durable2PC::Prepare to PS 
   2. PS sends Durable2PC::Prepared to CS 
   3. CS sends Durable2PC::Commit to PS 
   (PS suffers from internal failure) 
   (PA prevents any re-sent Commit from reaching PS) 
   4. Upon recovery, PS sends 2PC::Replay to CS 
   5. CS re-sends Durable2PC::Commit to PS 
   6. PS sends Durable2PC::Committed to CS  
   
   
  2. Scenario #5.2. RetryPreparedCommit
   
  In the description for the scenario, it states that 
   
              “This scenario tests recovery from a communication failure during the prepare phase. Once a durable participant (PS1) receives Durable2PC::Prepare message from Coordinator (CS), it attempts to send Durable2PC::Prepared message but this message never reaches CS (is lost). PS1 retries sending Durable2PC::Prepared and succeeds. Transaction is successfully committed.”
   
              How does PS1 knows that communication failure has taken place? After sending a “Prepared” message It will wait for the Coordinator to reply with a ‘Rollback” or a “Commit”. What event/State change makes PS1 to resend the “Prepared”? According to the specification, all the messages are “one way - fire and forget” (am I wrong on this?) messages, and therefore PS1 will not wait for an acknowledgement for the first “Prepared” message it sent. If the “Prepared” fail due to a communication failure, shouldn’t the Coordinator declare an abort upon reaching the timeout?  Could some one please provide an explanation for this?
   
   
  3. Scenario #5.3. RetryPreparedAbort. 
               In the message exchange steps it says  "CS may attempt to retry Durable2PC::Prepare to PS1. IA blocks those messages". Again, based on what does the Coordinator may retry sending "Prepare" message? Shouldn’t the Coordinator wait for the transaction timeout or all the participant reply with "Prepared", "Aborted" or "Replay”?
    I have implimeted an AT Corordinator on .NET and trying to test for the interoperability. I Appreciate kind feedback on the above. Thanks.
   
  Regards
  Sanjaya Amarasekera

 		
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1¢/min.