RE: Heuristics in BTP atoms

There is a timeout on PREPARED (formerly READY), which has more or less exactly the meaning you give - "I promise to be PREPAREd for the next 5 seconds" . The timeout is carried in a standard qualifier (decided at Mt Laurel, I think) but is very much part of the semantic. There was discussion of having a corresponding one on PREPARE, which would mean "please be PREPARED for at least T seconds, if you cannot make such a promise, then I'd rather have a CANCELLED now". I believe we decided to include that as another qualifier, but I'd have to check the mail archive to be sure.

But more fundamental, what it means to be PREPARED is only that the Participant will be able to confirm (make the changes permanent and beyond scope of reversal within the understanding of this biz transaction) or cancel (make the changes undone, reversed). But both confirm and cancel refer to the *shared* understanding of the application semantics, not anything that may be done in either end. If, as is very likely as you say, the whole is done by committing the work during the active phase and then, within the participant, compensating if it is cancelled, there are still potential time-constraints - more likely to be hours or days perhaps. But during that time an implementation (the underlying business system that offers the web service + participant) has to keep the cancellation available - it will perhaps not actually start anything irrevocable. In such a case, the confirm operation merely means the cancellation can be forgotten. During that period, though there may not be any database locks, there is still uncertainty as to whether the operations are going to apply - and the webservice might insist on imposing limits on how long it will remain in a state of (business) uncertainty.

Of course, conversely, if the implementation chooses to fulfil its PREPARED promises using XA (perhaps because contention possibilities are very low), it is no concern of the BTP protocol, or of the client / coordinator that it is doing so. The promise relates only to the shared understanding - more exactly the contracts between the parties - not to the mechanisms used within the end-systems.

In fact, in some cases, exactly what "cancellation" means might not be a perfect reversal even within the shared understanding - for example if cancellation incurs an administrative charge. But that's not really any different from getting a telecoms bill for the connection over which you ran the now-cancelled transaction. The key thing is that would be understood in the contract (ultimately legal contract, perhaps just stated in standard terms and conditions) - "you may order a bouquet of flowers, with the order controlled by BTP. If the order is cancelled less than 24 hours before delivery, there will be a $5 charge. We will automatically (autonomously) confirm the order 3 hours before delivery and charge the full amount, if no cancellation is received". What happens at the flower shop is no concern of the buyer.

BTW, as is mentioned in our draft paper on BTP that Alastair sent round, compensation has some shades of meaning that have confused some of our previous discussion. BTP enables the delegation of cancellation (CANCEL is sent to the flowershops participant, and that's all the buyer worries about). There is also cancellation by hand - phone up the flowershop and get them to cancel the order, identifying it by who bought it, who its to and what it is - that's what BTP packages and delegates for you. But quite different are various actions performed at either end (and quite independently) to counter the side-effects - the flowershop may reduce the price of flowers bought in specially; the buyer may get chocolates instead (or get drunk on his own). Those are out of scope of BTP. They would quite likely (in real examples) be controlled by the business process of the party in question.

business-transaction message