Fwd: Heuristics in BTP atoms

[Sazi Temel <sazi.temel@bea.com>]

FYI.

-----------------------//---------------------------------------------
Folks, 
As I mentioned in an earlier conf-call I am bringing
this issue to your attention. I have some concerns
regarding handling of heuristics in atomic BTP
transactions. I would like to hear your opinion before
I set it to rest. Since I have no access to my BEA
e-mail during the day thus messages I sent to oasis
list does not go through. I am sending this to a few
people who were involved in discussions with me
earlier. Please feel free to distribute it in the
list. 

Below an example (shown a message sequence of an atom
coordinator with two participants) of such heuristics
situation that my occur : 

 Coordinator ----PREPARE-------> Participant_1 
 Coordinator ----PREPARE-------> Participant_2 
 Coordinator <---PREPARED------- Participant_2 
 Coordinator <---PREPARED------- Participant_1 

 Coordinator ----CONFIRM--------> Participant_1 
 Coordinator ----CONFIRM--------> Participant_2 
 Coordinator <---CANCEL---------- Participant_1 (*) 
 Coordinator <---CONFIRMED------- Participant_2 

Now, one participant is prepared and one is canceled. 
The assumption here is that a PREPARE is only valid
for certain period of time. When a participant is
PREPARED it may include a condition such as "PREPARED
is valid for 5 sec only". And after that it may take
an either optimistic or pessimistic heuristic action. 

My concern is that this will yield a non-atomic
outcome and  BTP does not attempt to correct this
inconsistency. Although this situation looks like the
heuristics in 2PC I think it is different since 2PC
participants are usually in the same administrative
domain thus a corrective administrative action may be
easily taken. My concern is mostly based on my "guess"
that this situation (taking a heuristics action) will
occur more often in  atomic BTP transactions than 2PC,
mostly because a timeout for PREPARED will occur often
due to distributed and loosely coupled systems that
are involved in. 

Note that a message sent to Participant_2 to let it
UNDO the it's CONFIRM may help to bring the
participants in a consistent state  wrt transaction.
The action to take (undoing) depends on the
participant but BTP can let the participants know that
the transaction is not completed! Although BTP cannot
guarantee a common outcome (and will not be blocking
for-ever protocol), it should not let the participants
be in an inconsistent state, "knowingly" (ordered good
but no shipment is possible!) 

It looks like there is another (final outcome)"state"
after CONFIRM that a coordinator informs the
 participants that the transaction is completed and
they can forget any log that they may have on this
 particular transaction. 

I have not considered the performance and other
implications for the participants (such as keeping the
log - how long?) of including such a final-message
into the protocol.

Do you think we need such message? Is there such
message in the protocol?

Thanks.
--Sazi

----------------------------------//------------------------------------

---

Sazi Temel
Principal Consultant,
eCommerce Services, bea Systems, inc. [www.bea.com]

---