[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 3 -- proposal for discussion
Issue 29 deals with that. arkin Satish Thatte wrote: >[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]