Harvey,
It seems to me that the goal is not to "selectively kill scopes" but unload
them of variables that are no longer needed... or be able to create
partitioning/fragmentation strategies so that all variables are selectively
persisted and re-hydrated.
Edwin
> -----Original Message-----
> From: Harvey Reed [mailto:]
> Sent: Wednesday, October 08, 2003 1:31 PM
> To: 'Satish Thatte'; ;
> Subject: RE: [wsbpel] Issue 3 -- proposal for discussion
>
> Interesting, this exact point came up today in a meeting with
> our engineers.
> The question was whether there was a way to tell the
> persistent image of a scope that it can go away.
>
> Presumably, all scopes have to remain available until the
> outermost scope completes. I can't visualize how we could
> reliably and selectively kill "uneeded" scopes.
>
> ++Harvey
>
>
>
> -----Original Message-----
> From: Satish Thatte [mailto:]
> Sent: Wednesday, October 08, 2003 4: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
> >
> >
> >
> >
> >
> >
>
>
> 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/le
> ave_workgroup.
> php.
>
>
>
> 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/le
> ave_workgroup.php.
>
>
