On the Expressive Power of Primitives for Compensation

On the Expressive Power of Primitives for Compensation Handling Ivan Lanese Computer Science Department University of Bologna/INRIA Italy Joint work with Catia Vaz and Carla Ferreira

Error handling here?

Well…

Error handling l Many possible errors/unexpected events – Even in Cyprus – Even more in concurrent and distributed systems l Possible sources of errors – – l l Received data may not have the expected format Communication partners may disconnect Communication may be unreliable … A fault is an abnormal situation that forbids the continuation of an activity Faults should be managed so that the whole system reaches a consistent state

Compensation handling l l Managing errors requires to undo previously completed activities Undoing can not be perfect – Some activities can not be undone – Impossible to lock resources for long times l l The programmer defines some code (the handler) to take the system to a consistent state Handlers are associated to long-running transactions – Computations that either succeed or are compensated – Weaker requirement w. r. t. ACID transactions

Map of the talk l l l Comparing primitives for compensations A hierarchy of calculi Encoding parallel recovery An impossibility result Conclusions

Map of the talk l l l Comparing primitives for compensations A hierarchy of calculi Encoding parallel recovery An impossibility result Conclusions

Different primitives have been proposed l Different calculi and languages provide primitives for fault and compensation handling – BPEL, Sagas, St. AC, cjoin, SOCK, dcπ, webπ, … l l Are the proposed primitives equivalent? Which are the best ones?

A difficult problem l Approaches to compensation handling can differ according to many features – Flat vs nested transactions – Automatic vs programmed kill of subtransactions – Static vs dynamic definition of compensations l Approaches applied to different underlying languages – Differences between the languages may hide differences between the primitives

Our approach l l l Taking the simplest possible calculus (π-calculus) Adding different primitives to it Comparing their expressive power looking for compositional encodings Try to export the results to the original calculi Too many possible differences We concentrate on static vs dynamic definition of handlers – Other differences will be considered in future work

Static approach l The error recovery code is fixed – Java try P catch e Q – Whenever a fault is triggered inside P code Q is executed l l l This is the approach of Java, Webπ, πt-calculus, conversation calculus In general, recovery should depend on the computation done till now Possible approaches – Use nested try-catch blocks » More complex code – Or Q has to check the state to understand when the fault happened » Need for auxiliary variables, race conditions problem

Dynamic approach l The error recovery code can be updated during the computation – Requires a specific primitive for doing the update l Parallel recovery: new error recovery processes can be added in parallel – This is the approach of dcπ and the approach of Sagas and St. AC for parallel activities l General dynamic recovery: a (higher-order) function can be applied to the error recovery code – This is the approach of SOCK – BPEL, Sagas and St. AC use backward recovery for sequential activities » It is a particular form of general dynamic recovery

Map of the talk l l l Comparing primitives for compensations A hierarchy of calculi Encoding parallel recovery An impossibility result Conclusions

A hierarchy of calculi P : : = 0 Σi πi. Pi !π. P P|Q (νx)P t[P, Q] <P> X inst[λX. Q]. P inaction guarded choice guarded replication parallel composition restriction transaction protected block process variable compensation update π : : = a(x) a<v>

Simple examples: static compensations ! j h ij l Transactions can compute a b t[a(x): x: 0; Q] 0 t[b: 0; Q] l !h i j Transactions t t[a: 0; Q] can be. Qkilled l !h i Transactions can commit Q suicide t[t: 0 a: 0; Q] l ! h ijh i i Protected code is protected t[t: 0 a: 0 ; Q] a: 0 Q j jh

Simple examples: compensation update l l l ! b j c j Parallel update X. a: 0; Q] t[inst ¸X: P t[a: 0; P Q] ! b c Sequential update (backward) t[inst ¸X: b: X. a: 0; Q] t[a: 0; b: Q] b c Compensation t[inst ¸X: 0 deletion. a: 0; Q] ! t[a: 0; 0]

Race conditions l l l Should never happen that an action has been performed but the corresponding compensation update has not been done Otherwise in case of fault the compensation is not updated Compensation update should have priority w. r. t. normal actions

A hierarchy of calculi l l General dynamic recovery Parallel recovery – All compensation updates have the form λX. Q|X l Static recovery – Compensation updates are never used l l General dynamic recovery is more expressive than parallel recovery Parallel recovery and static recovery have the same expressive power

Map of the talk l l l Comparing primitives for compensations A hierarchy of calculi Encoding parallel recovery An impossibility result Conclusions

Encoding parallel update [[t b j [P; c. Q]]]p 2 s [[inst ¸X: Q X : P ]]p 2 s l l = = j (º r) t [[[P j h]]p 2 s ; [[Q]]p 2 sj r] i r: ([[Q]]p 2 s r) [[P ]]p 2 s Other constructs are mapped homomorphically to themselves Each transaction has an associated name r Compensations are stored in the body, protected and guarded by r Output on r is added to the static compensation and regenerated by stored compensations

Example of the encoding £ b j c [[t[book: inst ¸X: unbook X : pay: inst ¸X: ref und X ; 0]]p 2 s = (º r) t book: h j ij h j i j r: (unbook r) pay: r: (ref und r) ); 0 r]

£ execution Sample j ij h j i j £h (º r) t book: r: (unbook r) pay: r: (ref und r) ); 0 r] ¡¡¡! j ij h j i j £h book (º r) t r: (unbook r) pay: r: (ref und r) ); 0 r] ¡¡! h j ijh j i j pay ! (º r) t r: (unbook r) r: (ref und r) ); 0 r] ¡ h j ijh j i j h i t (º r) r: (unbook r) r: (ref und r) ) r ! h j ijh j i ¡ ¿ (º r) r: (unbook r) (ref und r) ) ! ¡ ¿ j ijh i (º r) (unbook r) ref und ) ¡¡¡¡! unbook ¡¡¡¡¡! ref und h h ijh i (º r) (r) ref und ) h ijh i (º r) (r) 0 )

Properties of the encoding l l The encoding is defined by structural induction on the term The process to be encoded is weakly bisimilar to its encoding – For processes that do not install compensations at top-level l The encoding does not introduce divergency

Map of the talk l l l Comparing primitives for compensations A hierarchy of calculi Encoding parallel recovery An impossibility result Conclusions

Conditions for compositional encoding 1. 2. 3. Parallel composition mapped into parallel composition Well-behaved w. r. t. substitutions Transactions implemented by some fixed context l With transaction name as a parameter 4. Process to be encoded should testing equivalent to its encoding l Only for well-formed processes l Weaker than asking weak bisimilarity 5. Divergency not introduced

Are the conditions reasonable? l l These or similar conditions have been proposed in the literature [Gorla, Palamidessi] Testing equivalence only for well-formed processes – Processes that do not install compensations outside transactions – Otherwise those compensations can be observed – Those compensations can never be executed l Sanity check: our previous encoding satisfies these properties

Impossibility result l l There is no compositional encoding of general dynamic recovery into static recovery Idea of the proof – With general dynamic recovery it is possible to understand the order of execution of parallel actions by looking at their compensations – With static this b or parallel c recovery j b is not possible c 0 0 l The process t[a: inst ¸X: a : 0 l has a trace a, b, t, b’ but no trace a, b, t, a’ This behaviour can not be obtained using static recovery b: inst ¸X: b : 0 ; 0]

Additional results l Asynchronous calculi – The impossibility result can be extended – One must require bisimilarity preservation instead of should testing preservation » Difficult to observe the order of actions otherwise l Backward recovery – Easily definable in a calculus with sequential composition – Even allowing to add a prefix in front of the old compensation is enough for the impossibility (λX. π. X)

Map of the talk l l l Comparing primitives for compensations A hierarchy of calculi Encoding parallel recovery An impossibility result Conclusions

Summary l A formaliztion of three different forms of recovery – Static, parallel and dynamic l l l An encoding of parallel recovery into static A separation result between those two and dynamic recovery What about calculi in the literature?

Exporting our results to other calculi Underlying language Compens. definition Protection operator Encoding applicable Impossib. applicable Dcπ Asynch. π Parallel Yes Asynch. Web π Asynch. π Static Implem. Yes Asynch. πt Asynch. π Static No No Asynch. Cjoin Join Static No Yes* No COWS - Static Yes No SOCK - Dynamic Implem. Yes No Jolie - Dynamic Implem. Yes No WS-BPEL - Static Implem. Yes No

Future work l Many questions still open – – l Nested vs flat What about BPEL-style recovery? What about c-join and calculi with priority? … We think that a similar approach can be used to answer them

End of talk

Application: dcπ l l l Dcπ is an asynchronous pi-calculus with parallel recovery Dcπ can be seen as a fragment of our calculus with parallel update of compensations The encoding works also in the asynchronous case, thus dcπ can be mapped into its static fragment

Application: webπ and webπ∞ l l Webπ∞ is an asynchronous fragment of our calculus with static recovery It is not possible to implement general dynamic recovery on top of it It is possible to implement parallel recovery Webπ has timed transactions, which add an orthogonal expressiveness dimension

Application: c-join l C-join is a calculus with static recovery based on join – Also some features of parallel recovery, since transactions can be merged l l Join patterns are more expressive than pi-calculus communication We conjecture that this gives the additional power required to implement general dynamic recovery

Application: Sagas, St. AC and BPEL l They use parallel recovery for parallel activities, backward recovery for sequential ones – More than parallel recovery, less than general dynamic recovery – The counterexample used in the impossibility theorem does not apply l Sagas and St. AC have no communication, so also observations are different