RE: [wsbpel] Issue 3 -- proposal for discussion

["Satish Thatte" <satisht@microsoft.com>]

One more time - this time with a more accessible JPEG picture courtesy
of Sid Askary.

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

compensation structure.jpg