Thanks Doug for the
clarification. This makes sense.
The approach that relies on PS2 retrying Prepared message (earlier
message) seems quite as valid as the approach that relies on CS retrying
Prepare message (your latest message), since upon communication timeout both
sides would attempt resending the message.
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Wednesday, June 28, 2006 2:57 PM
To: Ram Jeyaraman
Cc: Ian Robinson; ws-tx@lists.oasis-open.org
Subject: RE: [ws-tx] Interop scenario doc - scenario 5.1
Its not the
ordering the messages thats the concern its how we get the odd behavior to
happen. If I understand what Ian was saying (about the purpose behind
this scenario), its to have the Coordinator received a Prepared from a
participant that it already received a Prepared from - while still being in the
Preparing state. That's why we need the 2nd participant to not send in
its Prepared until PS1 sends in its 2nd one. So this means that our logic
needs to allow PS1's first Prepared thru but not allow PS2 to send one (or
block it from reaching the CS) until PS1 sends a 2nd one (and its received by
the CS). And, if I understand the spec correctly, we can't assume that
either PS will resend a Prepared unless we do something drastic like cause it
to fail/recover. So, I think the best way to avoid having PS2's Prepared from
reaching the CS is to not send it a Prepare to begin with - since getting it to
send another one (if we blocked the first one) would mean we'd need to have to
make it fail/recover - but then we'd get into some kind of race condition
between the two PS's recovering and that could get ugly.
I think
this should do it:
CS sends
Durable2PC::Prepare to PS1
CS sends Durable2PC::Prepare to PS2
(IA prevents
all Prepare's from reaching just PS2)
PS1 sends Durable2PC::Prepared to CS
(PS1 fails and recovers)
PS1 sends Durable2PC::Prepared to CS // Retry!
(Upon receipt at the CS, the
IA now lets all Prepare's thru to PS2)
CS resends
Durable2PC::Prepare to PS2
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
But I may be
misunderstanding the purpose behind Ian's change. :-)
thanks,
-Doug
Doug,
On
scenario 5.2:
Does
the ordering of the Prepared messages from PS1 and PS2 matter? In spite of the
race condition (steps 4 and 5), the coordinator CS would be forced to consume
the 2nd D2PC:Prepared message (either from PS1 or PS2).
I
modified the description a bit:
1. CS sends
Durable2PC::Prepare to PS1
2. CS sends
Durable2PC::Prepare to PS2
3. PS1 sends
Durable2PC::Prepared to CS. IA prevents the message from reaching CS.
4. PS1 resends
Durable2PC::Prepared to CS // Retry!
5. PS2 sends
Durable2PC::Prepared to CS
6. CS sends
Durable2PC:Commit to PS1
7. PS1 sends
Durable2PC::Committed to CS
8. CS sends
Durable2PC::Commit to PS2
9. PS2 sends
Durable2PC::Committed to CS
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Wednesday, June 28, 2006 12:04 PM
To: Ram Jeyaraman
Cc: Ian Robinson; ws-tx@lists.oasis-open.org
Subject:
RE: [ws-tx] Interop scenario doc - scenario 5.1
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
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