ws-tx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-tx] Interop scenario doc - scenario 5.1
- From: Doug Davis <dug@us.ibm.com>
- To: "Ram Jeyaraman" <Ram.Jeyaraman@microsoft.com>
- Date: Wed, 28 Jun 2006 17:56:38 -0400
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
"Ram Jeyaraman"
<Ram.Jeyaraman@microsoft.com>
06/28/2006 05:25 PM
|
To
| Doug Davis/Raleigh/IBM@IBMUS
|
cc
| "Ian Robinson" <ian_robinson@uk.ibm.com>,
<ws-tx@lists.oasis-open.org>
|
Subject
| RE: [ws-tx] Interop scenario doc - scenario
5.1 |
|
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]