[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: timeout and ..
Pal,
The time-out for PREPARE may or may not be in the protocol, perhaps I misunderstood
it.. Peter may give you better info on timeout. My point is that once an atom
is in a MIXED state (one participant is CONFIRMED and one is CANCELLED) the
coordinator should let the participant that is CONFIRMED to know that the
transaction is not completed as well as letting the participant that
CANCELLED know that is in a CONTRADICTION with the final out-come which it
does by sending CONTRADICTION message. This is like a 3P outcome instead of
2P outcome..
Also note that
1) When the initiator is Persistent Terminator (PT) it may receive
the MIXED message from Coordinator so that one may argue that the initiator
(PT) may contact the service already COMMITTED and let it know the final
out-come (kind of application level agreement which also requires that the
COMMITTED participant keeps the log on this transaction).
2) The above "solution" cannot work for a volatile terminator (VT) since it asks the coordinator commit by sending REQUEST_CONFIRM and the coordinator cannot return MIXED as reply because it is not a persistent terminator.
Again, I cannot remember whether if there is a time-out for PREPARE other
than atom's timeout and I may imply so in my previous e-mail, I apologize
for this.. but what I say above is not related to any special timeout that
may occur during the transaction. In fact the same situation (final out-come phase)
exist in cohesion too since it also reduces it self to an atomic outcome at the final stage.
I have no access to send this mail to the list, please distribute it for me.
Thanks.
--Sazi
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC