[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] installing compensation handlers for faulted scopes
Addendum: In a control flow, execution of an action (forward progress) is dependent on successful completion of prior action(s), otherwise the execution path is short-circuited at the point of failure. This simple assumption of successful completion of prior action(s), makes it easier for the developer in describing the process flow. If this assumption is taken away, then each action has to *adapt* its behavior depending on the outcome of prior action(s), which complicates the programming model. For example, <process> <sequence> <scope> <!-- Scope A --> ... <faultHandlers> ... </faultHandlers> <compensationHandler> ... </compensationHandler> </scope> <scope> <!-- Scope B --> ... <faultHandlers> ... </faultHandlers> <compensationHandler> ... </compensationHandler> </scope> </sequence> <faultHandlers> ... </faultHandlers> </process> Using the current model, Let us assume that a fault happens while processing scope A. A's fault handler compensates (undo) the original action, and does not rethrow the fault. Upon completion of fault handling, scope B is executed. When B begins execution, it needs to check the outcome of A, and behave accordingly, since its behavior is dependant on the outcome of scope A. That is, if A had completed without a fault, B may choose to perform action x, otherwise it would choose to perform action y. This is undesirable, and complicates the programming model. Due to this, the process description/logic becomes complicated. This has the inadvertant effect of forcing the developer to always rethrow a fault and not handle it, so as to short-circuit the control flow and avoid having to adapt to multiple possible completion states. Summary: If faulted scopes that do not rethrow faults were to be allowed to complete normally, the control flow becomes natural. This frees successor action(s) from having to adapt to multiple possible completion states of predecessor action(s), or rather allows the successor action(s) to make the simple assumption of successful predecessor completions, and simplifies the programming model. In that case, a fault handler may: 1. 'rethrow fault' implies that a fault handler failed in its attempt to handle the fault. This could mean that the handler attempted undo/redo and it failed during undo/redo. This also could mean that the handler simply does not want to handle the fault. 2. 'handle fault' implies that a fault handler succeeded in handling the fault. This means that the action has been successfully completed, just as it would have, if no fault had occured. That is, it is a *complete* recovery, not just an undo. This is an important semantic guarantee required for forward progress in a sequential control flow. Ram Jeyaraman wrote: > > issue: should a faulted scope be deemed successfully completed or not? > > currently, i beleive, a compensation handler is not installed for a faulted > scope, irrespective of whether the fault is propagated-up or not. > > i realize, as Satish pointed to, there are issues with allowing the fault > handler to attempt alternative normal completion. > > however, i would like to discuss this further to help convince ourselves that > we are embarked on the right model for fault/compensation handling. > > (a) Normally, if a fault handler were to be able to handle the fault itself, > that is, do corrective actions (both undo and redo), then the fault is not > rethrown, and the forward action can proceed as normally intended. > > (b) On the other hand, if the fault handler is not able to handle the fault, > perhaps it failed somewhere in its attempt to undo/redo, it rethrows the fault, > and the normal execution is short-circuited. > > in the case of (a), it seems reasonable to install a compensation handler, > since the fault was successfully handled, and forward progress can be made. If > this is not the case, the problem is that every forward action has to check if > the previous action(s) had successfully completed, which is non-trivial. In > such a case, the developer is most-likely going to almost *always* rethrow* a > fault in order to avoid having to check for every action if the previous one(s) > had successfully completed. > > in the case of (b), it seems reasonable to *not* install a compensation > handler, since the fault was not successfully handled, or rather the action did > not completed successfully. > > summary: the fact whether a fault was rethrown by a fault handler may be used > to decide whether to install a compensation handler or not. thanks. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]