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: Re: [wsbpel] Issue 3 -- proposal for discussion


i think we should carefully consider this restriction.  if we forbid
"variableName is itself a variable" then it will be impossible to prove
Goedel's incompleteness theorem using only BPEL.

[sorry.  couldn't resist]

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



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