OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-tx-comment message

[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]