RE: BTP without RM scenario

During the holiday period (apologies for launching a thread and then going
off-net), Ricky Ho sent:

>
> Under "BTP without RM" situation, lets assume the following happen.
>
> 1) Client initiate a BTP atom transaction
> 2) Client send a messageA to invoke operationA of Server
> 3) Client send a messageB to invoke operationB of Server (this message is
> lost !)
> 4) Client commit the transaction
>
> Let me skip the early part of underlying BTP interaction (e.g. obtain
> transaction id, enroll participant ... etc.) and jump to step (4) ...
>
> 4.1) Client send a "commit" to the co-ordinator (while thinking he is
> asking for completion of operationA and B)
> 4.2) Co-ordinator send a "prepare" to Server
> 4.3) Server respond a "perpared" to Co-ordinator (while thinking he is
> being asked for completion of operationA ONLY)
> 4.4) Co-ordinator continue to commit the transaction successfully
>
> BTP provides a 2-phase interaction protocol, but BTP doesn't address
> "Prepare for What ??", or "Commit what ??"  BTP assumes the "application
> state" has been exchanged reliably between the client and server.  And
> without RM, such guarantee is NOT POSSIBLE or have to be done at the
> application level.
>
> This seems to be more than just a protocol efficiency issue.

Yes, in general, with BTP (or any mechanism where one message refers to
another),
there is a need to consider the combination of the two, rather than treat
them
completely separately. (there is a difference between
saying "do this" and "be ready to do this when I say 'now'")

BTP does have a mechanism to ensure the consistency in this case - a
"CONTEXT-REPLY"
is sent back to the client to assure it that the enrollments implicit in the
sending of the CONTEXT (with messageA, messageB) have completed (or, in an
optimised case, will be completed before confirmation is attempted). If
there are
CONTEXT-REPLYs outstanding when the client requests confirmation, the
coordinator
will fault it (or wait, at implementation choice).

The problem with just using RM in this case would be that operationA has
been performed
(or is in some way in process, as a result of receiving messageA) when the
client gets
the report that messageB has been lost. So the client has to cope with more
complex
error cases.

Peter

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd

   Cohesions 1.0 (TM)
   Business transaction management software for application coordination

web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: +44 7951 536168
13 Austin Friars, London EC2N 2JX

Received on Tuesday, 7 January 2003 10:35:28 UTC