Ivan LaneseComputer Science Department

University of Bologna/INRIAItaly

On the Expressive Power of Primitivesfor Compensation Handling

Joint work with Catia Vaz andCarla Ferreira

Error handling here?

Well…

Error handling

Many possible errors/unexpected events– Even in Cyprus

– Even more in concurrent and distributed systems

Possible sources of errors– 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

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

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

Comparing primitives for compensations A hierarchy of calculi Encoding parallel recovery An impossibility result Conclusions

Map of the talk

Comparing primitives for compensations A hierarchy of calculi Encoding parallel recovery An impossibility result Conclusions

Different primitives have been proposed

Different calculi and languages provide primitives for fault and compensation handling– BPEL, Sagas, StAC, cjoin, SOCK, dcπ, webπ, …

Are the proposed primitives equivalent? Which are the best ones?

A difficult problem

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

Approaches applied to different underlying languages– Differences between the languages may hide differences

between the primitives

Our approach

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

The error recovery code is fixed– Java try P catch e Q– Whenever a fault is triggered inside P code Q is executed

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

The error recovery code can be updated during the computation– Requires a specific primitive for doing the update

Parallel recovery: new error recovery processes can be added in parallel– This is the approach of dcπ and the approach of Sagas and

StAC for parallel activities General dynamic recovery: a (higher-order) function can

be applied to the error recovery code – This is the approach of SOCK– BPEL, Sagas and StAC use backward recovery for sequential

activities» It is a particular form of general dynamic recovery

Map of the talk

Comparing primitives for compensations A hierarchy of calculi Encoding parallel recovery An impossibility result Conclusions

P ::= 0 inaction Σi πi.Pi guarded choice

!π.P guarded replication

P|Q parallel composition

(νx)P restriction

t[P,Q] transaction

<P> protected block

X process variable

inst[λX.Q].P compensation update

A hierarchy of calculi

π ::= a(x)

a<v>

Transactions can compute

Transactions can be killed

Transactions can commit suicide

Protected code is protected

Simple examples: static compensations

ahbi jt[a(x):x:0;Q] ! 0jt[b:0;Q]

tjt[a:0;Q] ! hQi

t[t:0ja:0;Q] ! hQi

t[t:0jha:0i;Q] ! ha:0i jhQi

Parallel update

Sequential update (backward)

Compensation deletion

Simple examples: compensation update

t[instb̧ X :P jX c. a:0;Q] ! t[a:0;P jQ]

t[instb̧ X :b:X c. a:0;Q] ! t[a:0;b:Q]

t[instb̧ X :0c. a:0;Q] ! t[a:0;0]

Race conditions

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

General dynamic recovery Parallel recovery

– All compensation updates have the form λX. Q|X

Static recovery– Compensation updates are never used

General dynamic recovery is more expressive than parallel recovery

Parallel recovery and static recovery have the same expressive power

Map of the talk

Comparing primitives for compensations A hierarchy of calculi Encoding parallel recovery An impossibility result Conclusions

Encoding parallel update

[[t [P;Q]]]p2s = (º r) t [[[P ]]p2s;[[Q]]p2s j r][[instb̧ X :Q j X c:P ]]p2s = [[P ]]p2s j hr:([[Q]]p2s j r)i

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

[[t[book:instb̧ X :unbook j X c:pay:instb̧ X :ref und j X c;0]]p2s =(º r) t

£book:hr:(unbookjr)i jpay:hr:(ref undjr)i);0 j r]

Sample execution

(º r) t£book:hr:(unbookjr)i jpay:hr:(ref undjr)i );0 j r]

book¡¡ ¡! (º r) t£hr:(unbookjr)i jpay:hr:(ref undjr)i);0 j r]

pay¡¡! (º r) t£hr:(unbookjr)i jhr:(ref undjr)i );0 j r]

t¡! (º r) hr:(unbookjr)i jhr:(ref undjr)i) j hri¿¡! (º r) hr:(unbookjr)i jh(ref undjr)i)¿¡! (º r) h(unbookjr)i jhref undi)unbook¡ ¡ ¡ ¡ ! (º r)h(r)i jhref undi)ref und¡¡ ¡ ¡ ¡! (º r) h(r)i jh0i)

Properties of the encoding

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

The encoding does not introduce divergency

Map of the talk

Comparing primitives for compensations A hierarchy of calculi Encoding parallel recovery An impossibility result Conclusions

Conditions for compositional encoding

1. Parallel composition mapped into parallel composition

2. Well-behaved w.r.t. substitutions

3. Transactions implemented by some fixed context With transaction name as a parameter

4. Process to be encoded should testing equivalent to its encoding Only for well-formed processes Weaker than asking weak bisimilarity

5. Divergency not introduced

Are the conditions reasonable?

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

Sanity check: our previous encoding satisfies these properties

Impossibility result

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 or parallel recovery this is not possible

The process

has a trace a,b,t,b’ but no trace a,b,t,a’ This behaviour can not be obtained using static recovery

t[a:instb̧ X :a0:0c j b:instb̧ X :b0:0c;0]

Additional results

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

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

Comparing primitives for compensations A hierarchy of calculi Encoding parallel recovery An impossibility result Conclusions

Summary

A formaliztion of three different forms of recovery– Static, parallel and dynamic

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 Yes Asynch.

Web π Asynch. π Static Implem. Yes Asynch.

πt Asynch. π Static No No Asynch.

Cjoin Join Static No Yes* No

COWS - Static Yes Yes No

SOCK - Dynamic Implem. Yes No

Jolie - Dynamic Implem. Yes No

WS-BPEL

- Static Implem. Yes No

Future work

Many questions still open– 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π

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π∞

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

C-join is a calculus with static recovery based on join– Also some features of parallel recovery, since transactions can

be merged

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, StAC and BPEL

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

Sagas and StAC have no communication, so also observations are different