[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] installing compensation handlers for faulted scopes
Let's say you are doing some activity in parallel of repeatedly, e.g. getting quotes from different suppliers. One of these instances encounters an unexpected fault and so cannot complete. The fault happens somewhere inside the activity, so it's handled very coarse grained, e.g. by doing compensation for any internal work. You now have three options: 1. The activity has completed and a compensation handler is installed. However, since it already did backward recovery, the logic for this compensation handler would be different then the one used had the activity completed without handling a fault. In this model you need two different compensation handlers, or more specific logic in the compensation handler (e.g. check if a fault occurred or not). 2. The activity completed but no compensation handler is installed. Since the activity was able to do backward recovery, it's overall effect is zero, so you can start a new instance (e.g. talk to a different supplier), or just continue doing the other instances (e.g. you may end up receiving only 2 quotes for the 3 RFQs you sent). This is a graceful way to get around errors and still get work done. 3. The only way the activity can not install a compensation handler is by throwing a fault. This model saves you from the need to define two compensation handlers (#1) but does not allow you to gracefully allow activities to fail and keep going about your business (#2). In our experience with business processes it seems that #2 is the most general case. It lets you distinguish between backward recovery before completion (fault handler) and backward recovery after completion (compensation), and handle failures gracefully. There is always the case where some activity A does a sequence of activities A1 and A2. Should A2 fail the activity A can still complete successfully and should be able to install a compensation handler. In this case it makes more sense to provide a fault handler for A2 that lets it complete, and then allows A to complete as if no fault happened. arkin 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]