[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Web Services Atomic Transaction Interop Scenarios - Simple Failure Model
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. Scen**ario #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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]