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