Issue 10 - Proposal to Vote (Revised)

["Satish Thatte" <satisht@microsoft.com>]

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