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

["Yaron Goland" <ygoland@bea.com>]

Is one of the practical consequences of proposal 2 that all scope variables
must be persisted when the scope successfully completes if either:
	A) The scope has a non-default compensation handler or
	B) The scope's variables are 'visible' from a scope with a
non-default compensation handler (e.g. imagine if S1 and S3 had compensation
handlers but S2 just had a default compensation handler. In that case S2
would still need to persist its variables since they would be 'visible' from
S3)?

Doesn't this seem a bit expensive? BPEL processes can run for months or even
years, building up lots of scopes all of whose variables would have to be
persisted. 

Might it not be more economical to include an attribute that can be included
on variable declarations to define which variables should be available for
use by compensation handlers? 

Couldn't static analysis then catch cases where a compensation handler
attempts to access a variable which has not been marked as being available
for compensation handlers?

	Thanks,

			Yaron

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Wednesday, October 08, 2003 7:07 AM
> To: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue 3 -- proposal for discussion
> 
> 
> 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
> 
> 
> 
> 
> 
>

<<attachment: winmail.dat>>