- From: Assaf Arkin <arkin@intalio.com>
- Date: Thu, 22 May 2003 11:20:20 -0700
- To: "Furniss, Peter" <Peter.Furniss@choreology.com>
- CC: Ricky Ho <riho@cisco.com>, Mark Little <mark.little@arjuna.com>, public-ws-chor@w3.org
Furniss, Peter wrote: >Assaf Arkin sent: > > > >>For atomic transactions you don't need prepare or commit, you are >>working at a higher level than the code and all that needs to be >>prepared or committed should be done by the engine for you. >> >> > >That assumes the participant side implementation treats atomic >transactions by delegating all resource operations to transaction-aware >RMs. That's certainly possible, but doesn't seem to be essential. > > If you are working with a low level programming language like Java you may need to do things at the end of the transaction. You will need a way to know about an intent to commit before it happens and know about the outcome after it completed, akin to afterCompletion/beforeCompletion. For example, to cache data and only store it at the end, to set the status of a session object, to do optimistic locking, etc. WS-TX has the proper flow to let you do that for atomic transactions. If you are working with a high level programming language like BPEL, which is not intended to replace Java, you don't do these low level operations. The BPEL engine can do caching, optimistic locking, etc because it receives the signals it needs to do that. But what you are writing depends on a smart engine taking care of these things, not on doing work at that level of detail. We do not have a single use case where people would like to have high level process definitions which are best addressed by languages like BPEL or BPML, and at the same time want to do low-level things that require access to these signals. When it gets down to nitty gritty details they tend to prefer to work with languages like Java. > > > >> For BA >>transactions you don't have prepare or commit, every response is an >>indication that all previous steps have been completed (prepared and >>committed). You do need a way to cancel, but this can be done >>by a fault >>handler (the terminate fault). And you do need a way to >>compensate and >>this is done by a compensation handler. >> >> > >It's a major bug in the current WS-T that it exposes, in the inter-party >protocol, how the participant handles its resources and delivers on its >"promise" to obey a subsequent cancel. That seems inappropriate to this >world of "loosely coupled" systems. Obviously, in some cases, the >contract between the systems may cover the degree of exposure of the >intermediate results, and in what circumstances faults might occur (WS-T >BA cannot communicate a failure of committed, closed transaction because >it is locked to a perform, compensate approach). But that's detail on >the fundamental, common to any coordination pattern, that all the >players have to make their final state dependent on a single decision >(strictly, all but one, since the decider can be a resource-holder). > > I disagree. In asynchronous messaging you know that any response you get is a commitment to the previous steps taken. There are a lot of different ways to implement this. It may include persisting at the end of every step, or just logging all events and replying them at the end, or creating an end-state in some temporary place and pushing it at the end. I've seen many different models to implement it, and all of them seem consistent with the specification so it is loosely coupled in the sense that it does not propose any single model, and I doubt if all the vendors implementing this spec do it exactly the same way. But since we are talking about interactions that cannot be rolledback but only compensated, the 2PC flow doesn't work with most of these systems. The flow that does work is based on either asking to cancel or compensate work, and responding not with a vote but with the outcome, which can be compensated if required. arkin >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 Thursday, 22 May 2003 15:55:10 UTC