ws-kandula-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjaya Amarasekera <cron...@yahoo.com>
Subject Web Services Atomic Transaction Interop Scenarios - Simple Failure Model
Date Tue, 15 Aug 2006 08:20:33 GMT
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.
Mime
View raw message