[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:]
Sent: Wednesday, October 08, 2003 3:17 PM
To: Satish Thatte;
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:]
> Sent: Wednesday, October 08, 2003 1:26 PM
> To: ;
> 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:]
> Sent: Wednesday, October 08, 2003 1:10 PM
> To: Satish Thatte;
> 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:]
> > Sent: Wednesday, October 08, 2003 7:07 AM
> > To:
> > 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
> >
> >
> >
> >
> >
> >
>
>
