[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [wsbpel] Issue 3 -- proposal for discussion
Better formatted version of the same mail .. BPEL currently specifies that a compensation handler lives in a snapshot world in which the state of the associated scope and all enclosing scopes has been preserved as it was when the associated scope completed. There is an outstanding BPEL issue (Issue#3) that points out that there is a need for compensation handlers to affect and be affected by the "current state of the world". Proposal #1: The proposal on the table has been to add inbound and outbound parameters to compensation handlers to allow invokers of compensation to send data into and get data out of the compensation process. Proposal #2: Choreology put an alternative proposal on the table. Restated, it basically says that compensation handlers always see the current state of the world. The current state of the world for completed scopes is their state as it was at the time of completion. They are in suspended animation because their compensation handlers are still alive and therefore their execution may "continue" in compensation mode. Thus for enclosing scopes the compensation handler either sees live state (if the scope is not completed) or the state of the scope as it was when that scope completed. In the attached picture showing three nested scopes S1, S2 and S3, their compensation handlers C1, C2, C3, and failure handlers F1 and F2, we may have an error handling call stack F1->C2->C3. In that case C3 will see the state of S2 as it was when S2 completed. However that is also what C2 is seeing and C2 has called C3, therefore there is a consistency of visible state in the call stack. The positives and negatives of these two proposals mirror each other. A positive aspect of the second proposal is that parameters are not needed for data flow to and from live state to compensation handlers, and compensation handlers with live state contact can be used in default compensation, unlike the first proposal. The negative aspect is that compensation handlers will now participate in concurrency control issues relating to live state, and will need to use serializable scopes when they touch non-local state, again unlike the first proposal. The concurrency control problem also has an impact on Issue#10 which deals with serialization of compensation handlers. On the whole, given the alternatives, the second alternative is preferable, especially because it maintains default compensation semantics. I propose to resolve Issue 3 along the lines of the Proposal #2. Satish
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]