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

[Harvey Reed <hreed@sonicsoftware.com>]

Interesting, this exact point came up today in a meeting with our engineers.
The question was whether there was a way to tell the persistent image of a
scope that it can go away. 

Presumably, all scopes have to remain available until the outermost scope
completes. I can't visualize how we could reliably and selectively kill
"uneeded" scopes.

++Harvey



-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com] 
Sent: Wednesday, October 08, 2003 4:26 PM
To: ygoland@bea.com; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 3 -- proposal for discussion

Yaron,

It should be fairly straightforward to detect which non-local variables
are actually used in compensation handlers and persist only those.  What
you are suggesting is an extra annotation that allows additional
verification of intent via redundancy.  Seems OK though a bit onerous,
and nothing at all to do with cost.  Do other people have opinions?

The bigger issue for cost is detecting when a scope snapshot is no
longer needed because there is no "path" left to invoke it.  In other
words, snapshot GC.

Satish

-----Original Message-----
From: Yaron Goland [mailto:ygoland@bea.com] 
Sent: Wednesday, October 08, 2003 1:10 PM
To: Satish Thatte; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 3 -- proposal for discussion

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
> 
> 
> 
> 
> 
> 


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.