OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Issue 3 - Proposal to vote

The proposed resolution of Issue#3 overrides the semantics of variable usage in compensation handlers as described in Section 13.3.1.   The discussion thread associated with this issue is also worth reading for background.

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. The handler is able to assign new values to the variables visible to it in all scopes, but the assignment affects only the snapshot.  The specification further anticipates Issue#3 and a potential resolution 

"It is not realistic to expect compensation activities to always be oblivious to the current state of the world. In fact, compensation both affects and is affected by the current state. However, the shape of the world within which compensation is run is difficult to anticipate. It is therefore necessary to allow the two-way interaction between compensation activities and the live world to take place in a tightly controlled manner. In the future, BPEL4WS will add input and output parameters to compensation handlers for this purpose."

The proposal stated here is to eliminate the notion of a snapshot world from the semantics of the relationship between compensation handlers and variable state (including the state of partnerLinks).  This addresses Issue#3 without the use of parameters.  The relevant text in Section 13.3.1 would be replaced with the following (the picture would also be included in the specification)

Compensation handlers always interact with the current state of the process, specifically the state of variables declared in their associated scope and all enclosing scopes.  The variables include partnerLinks at the process scope.  Compensation handlers are able to both get and set the values of all such variables.  Other parts of the process will see the changes made to shared variables by compensation handlers, and conversely, compensation handlers will see changes made to shared variables by other parts of the process, including situations where a compensation handler runs concurrently with other parts of the process.  Compensation handlers will need to use serializable scopes when they touch state in enclosing scopes to avoid interference.

The current state of the process consists of the current local state of all scopes that have been started.  This includes scopes that have completed but for which the associated compensation handler has not been invoked.  For completed uncompensated scopes their current local state is the state as it was at the time of completion. Such scopes are in suspended animation because their compensation handlers are still available and therefore their execution may continue in compensation mode.  Note that a scope may have been executed several times in a loop, and the current state of the process includes the state of each completed (and uncompensated) iteration through the scope.  

The behavior of a compensation handler can be thought of as an optional continuation of the behavior of the associated scope and as such its usage of variables is similar to the usage that occurred in the body of the scope itself, including update actions.   This includes variables in both the local scope and all enclosing scopes.  Note that the compensation handler may itself have been called from an enclosing compensation handler.  It will then share the continuation of the state of the enclosing scope that its caller is using.  In the attached picture showing three nested scopes S1, S2 and S3, and 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 share the state of S2 as it is being seen and used by C2.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]