[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 10 - Proposal to Vote (Revised)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]