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

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

[Yaron] Since one can use getVariableData functions whose variableName
is itself a variable one must use annotations otherwise one has to
persist all values.
[Satish] I believe we should ban "variableName is itself a variable".
Do we have an issue to discuss the matter?  Paco were you going to
follow up on this one?

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

That's it! Thank you. When I wrote up the letter something was really
bugging me but I couldn't figure out what it was and so eventually just
sent the letter. Your letter reminded me what was bugging me.

Since one can use getVariableData functions whose variableName is itself
a variable one must use annotations otherwise one has to persist all
values.

So the answer to the last question in my letter is - No, static analysis
cannot always determine when a compensation handler has accessed a
variable that has not been marked for 'freezing'. Instead we will have
to have runtime checking that can throw a fault if a getVariableData
function should have a variableName argument whose value does not
resolve to a 'frozen' or 'live' value.

		Yaron



> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Wednesday, October 08, 2003 1: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
> > 
> > 
> > 
> > 
> > 
> > 
> 
>