Thoughts on Error Handling and Compensation Issues

1
Thoughts on Error Handling and Compensation Issues

• Satish Thatte
• Microsoft

2
Issue 1 Permeability of Scopes

• Links are usually used to expressed dependencies
  between activities AgtB means B is dependent on
  successful completion of A
• Problem AgtB may need to cross the boundary of
  the scope that encloses A
• Allowing such a link to leave As scope before
  its completion creates conundrums if the scope
  later faults and compensates A
• The assumptions made by B about the results of A
  are made invalid and the rug is pulled from
  under Bs feet without its knowledge
• Proposed solution In case of links that cross
  scope boundaries, make the link status available
  at the target only after all intervening scopes
  have completed successfully.

3
Issue 3 Current State Influence in Compensation
Handlers

• Core of the issue tension between snapshot state
  and current or live state visibility
• Current spec only allows visibility to snapshot
• includes entire chain of enclosing scopes
• Proposal 1 Allow only local snapshot state and
  use in and out parameters for all data influence
  outside current snapshot
• Proposal 2 allow all live non-local enclosing
  scope state to be visible to compensation
  handler, confine the snapshot to local state
  associated with the scope being compensated

4
An Example of Compensation Structure
F1
F2
What is the state visible here for S3, S2 and
S1?
S3
C3
S2
C2
S1
C1
5
Issue 3 Continued examine Proposal 2

• The fault causing compensation of S3 (invocation
  of C3) may have occurred in S2 or S1 or in a
  scope enclosing S1
• The possible combinations of live and snapshot
  state are very confusing
• If C3 is indirectly invoked from F1, C3 will see
  a snapshot of S2 that occurred at a different
  point than the completion of S3
• I believe that modeling C3 will become
  exceedingly difficult under this proposal

6
Issue 10 Serialization of Default Compensation
Handler Invocation

• In case default behavior is used, what is the
  order in which compensation handlers are invoked?
• The spec says If the compensation handler for a
  scope is absent, the default compensation handler
  invokes the compensation handlers for the
  immediately enclosed scopes in the reverse order
  of the completion of those scopes
• This addresses order within a scope but does not
  take account of ordering dependencies across
  scopes
• Also it does not permit concurrent invocation of
  handlers
• One may say that the order should simply reverse
  the known ordering dependencies for the scopes
  themselvese.g., links between scopes
• However serializability imposes a less obvious
  ordering dependency that is only realized at
  runtime in a nondeterministic fashion
• We need to look very carefully at what guarantees
  we think we want to and can provide in this case
• Proposal Schedule resolution for next F2F

7
Issue 20 Installing compensation handlers for
faulted scopes

• BPEL allows compensation only for scopes that
  complete successfully
• A scope that has a fault handler associated with
  it invoked at some point is deemed to always
  complete unsuccessfully
• The reasoning for this design is that the default
  or custom compensation behavior for a scope that
  has had fault handlers invoked is almost
  impossible to fathom
• Ram Jeyaraman has proposed that further
  discussion on this issue is needed

8
Issue 25 Consistent enablement of compensation
handlers

• There are two interpretations for the absence of
  an explicit syntactic compensation handler being
  provided for a scope
• Use default compensation (current semantics)
• Perform no compensation
• The issue seems to reduce to the choice of
  interpretation
• Explicit syntactic means must be provided for the
  other interpretation
• It is not clear that one or the other
  interpretation is better, unless someone can make
  that argument
• Proposed Resolution keep the Status Quo

9
Issue 27 Setting link status in case of
transition condition

• This appears to be a special case of the problem
  addressed by Issue1.
• Proposed resolution treat the evaluation of
  transition conditions for links leaving the scope
  as part of the computation within the scope.
  Thus the scope cannot be considered successfully
  completed until these transition conditions have
  been evaluated