Default Compensation Order Satish Thatte Dieter Roller

Current Statement is Imprecise Current Statement is Run all available compensation handlers for immediately enclosed scopes in the reverse order of completion of the corresponding scopes Implies stack unraveling order to most people Problematic implications in the presence of concurrency and control links We need to define a partial order that respects completion at leaf scopes

Restatement of the Problem Default compensation traverses a tree of compensation handlers for successfully completed scopes starting from the original fault handler Real compensation occurs at the leaves where custom handlers are The order among these leaf scopes is the semantically significant question The reverse order could be about respecting Modeled order imposed by the process definition Contingent order imposed by resource contention Contingent order is hard to keep track of Must account for potential as well as actual contention

A B C E F G D H I S1S2 S3 Bold activity circles have custom compensation handlers Arrows indicate control dependencies such as sequence or link

Needs Flipping Between Stacks The operation of custom compensation handlers depends on a stack of parent scope handlers for shared state Per resolution of Issue#3 Multiple of these stacks will need to be simultaneously active during default compensation as shown on the next slide

Compensation Order for the example S3 S2S1I CABFH Compensation order indicated by numbering