Re: [wsbpel] Issue 10 - Proposal to Vote (Revised)

[Danny van der Rijn <dannyv@tibco.com>]

+1

previous attempts to solve this problem have been too complex.  imo, 
this solution has just the level of complexity needed to solve the 
problem, and no more.


Satish Thatte wrote:

>Alex found one omission (added below as Part III), one point needing
>clarification (added as a Clarifying Note in Part II) and one point for
>further discussion (mentioned at the end) in this proposal.  There are
>other minor wording changes to add explanations to make a few things
>more explicit.  Also added Dieter Roller to the list of proposal
>authors, since he was involved substantially in earlier discussion on
>this issue.
>
>Clearly, I need to start getting things reviewed by Alex just before
>posting them ;-)
>
>Revised Proposal:
>
>Informally, we propose that default compensation order need only respect
>the control dependencies that are explicitly modeled.  With the proposed
>resolution of Issue 1, it is far from easy to emulate strict reverse
>order of completion with explicit fault and compensation handlers.  But
>with the proposed resolution of Issue 10 here, that does not matter
>since strict reverse order is permitted but not mandated for the default
>behavior.  This does require an additional restriction on links to ban
>reentrant control paths, as described below more formally.
>
>Definition:  Control Dependency.  If an activity A must complete before
>activity B begins, as a result of the existence of a control path from A
>to B in the process definition, then we say that B has a control
>dependency on A.  Note that control dependencies may occur due to
>control links in <flow> as well as due to constructs like <sequence>.
>Control flow due to explicit "throw" is not considered a control
>dependency.
>
>Part I:  Consider scopes A and B such that B has a control dependency on
>A.  Assuming both A and B completed successfully and both must be
>compensated as part of default compensation behavior, the compensation
>handler of B must run to completion before the compensation handler of A
>is started.  This permits scopes that executed concurrently on the
>forward path to also be compensated concurrently in the reverse path.
>Of course, if one follows the strict reverse order of completion, then
>that necessarily respects control dependencies and is also consistent
>with this rule.  The rule imposes a constraint on the order in which
>compensation handlers run during default compensation, and is not meant
>to be fully prescriptive about the exact order and concurrency. 
>
>
>Definition:  Reentrant control path.  Consider activities A and B
>enclosed in a scope S, such that B has a control dependency on A.  The
>control path from A to B is said to be reentrant if it includes an
>activity C that is outside scope S, i.e., there is an activity C outside
>scope S such that C has a control dependency on A and B has a control
>dependency on C.  Informally, such a reentrant path starts at A, "leaves
>scope S" to reach activity C and then "reenters scope S" to reach
>activity B.  Note that reentrant control paths always involve links, at
>the least, one to leave the scope and one to reenter the scope.
>
>Part II:  It is necessary to be able to define the default compensation
>behavior of a given scope independent of its peer and enclosing scopes.
>One reason is that such a default compensation handler may be invoked
>explicitly by the fault and compensation handlers of its enclosing
>scope.  However, there are currently legal cases where the proposed
>resolution in Part I makes this impossible.  One such example is
>attached.  We propose to resolve this by banning reentrant control
>paths.  This restriction would be added to the list of restrictions on
>links at the end of section 12.5.  Clarifying note: all reentrant
>control paths are banned according to this proposal, whether or not they
>involve scope activities.
>
>Part III:  Given that compensation handlers may run concurrently with
>other activities including other compensation handlers, it is necessary
>to allow compensation handlers to use isolation scope semantics.
>Compensation handlers do not run within the isolation domain of their
>associated scopes, but fault handlers do.  This creates difficulties in
>the isolation semantics of compensation handlers for scopes nested
>inside a serializable scope.  Such handlers cannot use serializable
>scopes themselves because serializable scopes cannot be nested.
>However, their isolation environment is uncertain because they may be
>invoked from either a fault handler within the isolation domain of their
>enclosing scope or within the compensation handler of the same enclosing
>scope which is not in that isolation domain.  In order to improve
>consistency of behavior, we propose that the compensation handler of a
>serializable scope will itself have serializable behavior implicitly,
>although it will create a separate isolation domain from that of its
>associated scope.
>
>Point for discussion:  As stated above, Part I imposes a constraint on
>the order in which compensation handlers run during default
>compensation, and is not fully prescriptive about the exact order and
>concurrency.  There is some internal debate among the proposal authors
>on this point, which we propose to carry on in the broader forum at the
>F2F.
>
>Nick Kavantzas
>Frank Leymann
>Dieter Koenig
>Dieter Roller
>Satish Thatte
>Alex Yiu
>
>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.
>
>  
>