OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] installing compensation handlers for faulted scopes


Ram Jeyaraman wrote:

>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.
>  
>
Another possibility:

3. 'throw a new fault' implies that the fault handler may have succeeded 
to undo/redo the activity and so the activity has been recovered. 
However, the activity did not return any outcome that is useful for 
activity B and so activity B should not execute.

For example, activity B may require an allocation of two products. This 
is the expected outcome of activity A. Activity A may succeed in 
allocating one but fail in allocating the other. It's fault handler is 
capable handling the fault and undoing the damage by de-allocating the 
first product, making it available for other orders. But it cannot 
provide B with a usable outcome, and indicates to by throwing a 
different fault. Where the original fault may have been 'item X not 
recognized' then thrown fault may be 'allocation failed' with the detail 
'item X not recognized'.

arkin





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]