Guarantees and Protocols: Abstractions for Recovery

Krithi Ramamritham, IIT Bombay

(with Cris Pedregal-Martin)

2

transactions and recovery review

Transactions: all-or-nothing semantics• if transaction commits, all updates made permanent

• if aborts, no updates ever visible to others a.k.a. Failure Atomicity and Durability (FA+D)

Recovery supports all-or-nothing– uncommitted updates undoable (never happened)– once committed, database reflects updates

in spite of failures

3

transactions are everywhere!

applications:

• e-commerce, workflows

• mobile systems

• design, document management, etc.

want variants of transaction semantics– tailored to application, platform

– to get benefits of recovery, concurrency

4

we focus on Recovery

liveness wrt failures:

Recovery enables a system

to make progress

in spite of (temporary) failures

we assume simple temporary failures

e.g., loss of volatile memory, communication

5

outline for talk

recovery beyond databases very desirable

…but hard to get right

• our approach & contributions

• e-commerce

• mobile system

• related work

• summary and future work

7

recovery is hard to get right

• cuts through all system levels– failure functionality - performance intertwined

e.g., fine control over storage management

• recovery is custom-made– very good database solutions (e.g. ARIES)– but, hard to (re) deploy, adapt:

change infrastructure, effect on high-level semantics?

change high-level, what’s required of infrastructure?

no easy answers

8

example: delegationhigh-level primitive for advanced transactions

e.g. nested, split trans. obtained with delegation

T1 delegates operation p to T2

p’s fate is now tied to T2’s• e.g. T2 commits then p appears even if T1 aborted

delegation “rewrites history” (p by T2 not T1)

to support it, modify low-level recovery

nontrivial in e.g. ARIES!

Delegation: Efficiently Rewriting History, in 13th ICDE, 1997

9

we want abstraction in recovery

• goal: separate what from how of recovery• approach:

– find common ingredients & their roles– formalize & use to describe recovery

• implicit temporal predicates (liveness)

– decompose / describe:• application-level semantics down to

implementation-level mechanisms (vertical)• recovery obtained from autonomous

components (horizontal)

10

contributions: framework & examples

1. framework to specify & reason about recovery– guarantees: recovery expectations of components

e.g., Bank will pay authorized charge, even under failures

– protocols: legal component behaviorse.g., authorize charge happens-before confirm order (Merchant)

forced protocols: progress of application

specifications separate what from how

2. applied to case studies– e-commerce– database recovery– mobile systems

11

outline for talk

recovery necessary but hard to get right

our approach & contributions

e-commerce

• overview, framework, layered spec. & proofs

• mobile system

• related work

• summary and future work

13

e-commerce timeline

open-order

begin-order

Merchant

Customer

time

14

e-commerce timeline

open-order

begin-order

Merchant

Customer

time

auth?

authOK

Bank

GBM

Bank promises Merchant it will pay charge

15

e-commerce timeline

open-order

begin-order

Merchant

Customer

time

auth?

authOK

Bank

SupplierallotOK

allot?order-OK

GBM

GSM

Supplier promises Merchant it will ship

Merchant can commit

16

e-commerce timeline

open-order

begin-order

Merchant

Customer

time

auth?

authOK

Bank

SupplierallotOK

allot?order-OK

pay-bank

bill-customer

pay-merchant

charge-bank

order-received

order-shipmentpay-supplier

ship-goods

bill-merchant

end-order

GBM

GSM

Merchant commits order to Customer

19

e-commerce timeline observations

• money-goods atomicity ensured by– each component honors its guarantee and

makes progress– each guarantee becomes enabled – once Merchant confirms order, inevitably each

guarantee is triggered, so eventually discharged– discharge of each guarantee pays or delivers

• no need to look inside the components

20

elements of the framework

• system history and actions/events• partial order on data operations, commit, abort, ...

• components - • subsystems that offer/use guarantees

• guarantees (liveness) - promise future events• enable, trigger, discharge events/actions• components that request and that honor guarantee

• protocols (safety) - prescribe legal histories• happens-before relationship between events

– forced protocols (liveness)• operation sequences will make progress

21

partial layers e-commerce scenario

order confirmed money exchanged for goods

Bank pays Merchant & ...

Bank’s DB Transactions Guarantees

GBM enabled, triggered, discharged

Bank supports GBM to Merchant

Database Recovery support

Merchant - Bankmessages

Bank Applicationuses Transactions

Database supportscommit, abort

Buffer Mgmt,Disk persistence

22

money for goodsM C orderOK H

Merchantpays

Supplier

Customerpays Bank

Supplier ships goodsto Customer

Bank paysMerchant

& & &

23

money for goods

Bank’s internalssupport GBM

GBM enabled GBM triggered

M C orderOK H

Merchantpays

Supplier

Customerpays Bank

Supplier ships goodsto Customer

Bank paysMerchant

GBM discharged& & &

24

money for goods

Bank’s internalssupport GBM

GBM enabledB M authOK H

GBM triggeredM B charge H

orderOK H MP1: authOK orderOK

M C orderOK H

Merchantpays

Supplier

Customerpays Bank

Supplier ships goodsto Customer

Bank paysMerchant

GBM discharged& & &

MP1: Merchant’s workflow engine (scheduler)

25

money for goods

Bank’s internalssupport GBM

GBM enabledB M authOK H

GBM triggeredM B charge H

orderOK H MP1: authOK orderOK

Xauth, Xpaytransactions

M C orderOK H

Merchantpays

Supplier

Customerpays Bank

Supplier ships goodsto Customer

Bank paysMerchant

GBM discharged& & &

MP1: Merchant’s workflow engine (scheduler)

26

money for goods

Bank’s internalssupport GBM

GBM enabledB M authOK H

GBM triggeredM B charge H

orderOK H MP1: authOK orderOK

orderOK H MFP4: orderOK charge

Xauth, Xpaytransactions

Database TMS

M C orderOK H

Merchantpays

Supplier

Customerpays Bank

Supplier ships goodsto Customer

Bank paysMerchant

GBM discharged& & &

MP1: Merchant’s workflow engine (scheduler)

27

money for goods

Bank’s internalssupport GBM

GBM enabledB M authOK H

GBM triggeredM B charge H

orderOK H MP1: authOK orderOK

orderOK H MFP4: orderOK charge

Xauth, Xpaytransactions

Database TMS

M C orderOK H

Merchantpays

Supplier

Customerpays Bank

Supplier ships goodsto Customer

Bank paysMerchant

GBM discharged& & &

MP1: Merchant’s workflow engine (scheduler)

MFP4: Merchant’s workflow engine (recovery)

Disk

28

prove one:order confirmed merchant

paid

Merchant Customer Bank Supplier

(S, C, shipment: x)

(M, S, payment: p)

(B, M, payment: p)

(C, B, payment: p)

29

how order confirmed merchant paid

Prove MC orderOK H BM payment H

30

how order confirmed merchant paid

Prove MC orderOK H BM payment H

Hint: BM payment = dischargeGBM (Bank will pay auth. charges)

Prove: GBM supported, enabled, and triggered

31

how order confirmed merchant paid

Prove MC orderOK H BM payment H

Hint: BM payment = dischargeGBM (Bank will pay auth. charges)

Prove: GBM supported, enabled, and triggered

• Bank supports GBM - given by its database

32

how order confirmed merchant paid

Prove MC orderOK H BM payment H

Hint: BM payment = dischargeGBM (Bank will pay auth. charges)

Prove: GBM supported, enabled, and triggered

• Bank supports GBM - given by its database

• enableGBM H via: MC orderOK H BM authOK H

– protocol P1: BM authOK MC orderOK

33

how order confirmed merchant paid

Prove MC orderOK H BM payment H

Hint: BM payment = dischargeGBM (Bank will pay auth. charges)

Prove: GBM supported, enabled, and triggered

• Bank supports GBM - given by its database

• enableGBM H via: MC orderOK H BM authOK H

– protocol P1: BM authOK MC orderOK

• triggerGBM H via: MC orderOK H MB payreq H

– Merchant forced protocol P5 - by its application engine

– pre(MB payreq) = (enableGBM H MC orderOK H)

36

how Bank supports guarantee Merchant

GBM: Bank will pay Merchant authorized charges, even under failures:

• transaction Xauth commits authorization data– authID will be recognized when presented

• transaction Xpayout responds to charge request– finds authorization info via authID, commits payment

• each Merchant request ack’d at commit

Merchant will charge, by its forced protocol

Database Transaction semantics given

41

e-commerce observations• transactional semantics

• M C Order OK is like transaction commit

• recovery support ensures sale completes

• abstraction:– prove properties one layer at a time– can spec. component w/out others internals

• easy to specify alternatives• Merchant self-authorizes under some amount

• Merchant escrows goods at Supplier

42

outline for talk

recovery necessary but hard to get right

our approach & contributions

e-commerce

mobile system

• overview, challenges, specification,

observations

• related work

• summary and future work

43

mobile system

S

A

B

fixed network

handoffbasestation

server

Mmobile

44

mobile system

S

A

B

fixed network

handoffbasestation

server

Mmobile

45

mobile system challenges

• handoff dynamically reconfigures network• mobile doze/suspend partitions network• limited storage on mobile host, base station

problem:

• preserve recovery for mobile when it migrates– operations done while M at A– commit / recovery when M at B

solution: handoffs do some recovery work

46

handoff variants

• propagation of recovery information– eager, during normal processing– lazy, during repair processing– directly or via another mobile host

• location of persistent recovery information– at base stations– at central server

for the different variants, support recoverability

47

mobile system layers

p recoverablewhile M at A

mobile host /whole system

Gslog(A,M)Pslogsend(A,M)Pslog(A)

ORAND

AND

mobile host /base station

host's recoverysubsystem

recovery subsystem'sdisk

Gslog(RS , A)Pslog(RS )

AND

A

Gpersistlocal disk to RSA

Gpersist disk at S to RSA

GcommRS and SA

p recoverablewhile M at B

Ghndf (A,B)

M migrates to B hndf (M, B) A

Phndf (A,M,B)

M executes pwhile at A

AND

A

PwalRS and S

E Gcomm(A,B) & (B,A)

Gloghndf(B)

Pcommhndf

Gslog(A,M)

48

mobile system observations

• characterized variants & showed how recovery supported regardless of variant

• exposed unstated assumptions about handoffs when proving recovery properties

• proved how higher-level obtained from lower level guarantees

49

related work

• ARIES: database recovery, specification

• Sagas, ACTA: advanced transaction models

• Phoenix: recovery for office application

• ProMotion: mobile transactions

50

contributions

• framework:– identified & formalized common ingredients– used ingredients to separate what from howused framework to reason about examples:

• e-commerce– “liveness” from autonomous partsGuaranteeing Recoverability in E-Commerce, in 3rd WECWIS, 2001

• mobile systems– exposed assumptions, novel scenarios...Recovery Guarantees in Mobile Systems, in MobiDE, 1999Support for Recovery in Mobile Systems, in IEEE Trans on Computers, Oct, 2002

52

future workextend framework

– examples: ARIES variants, client-server, apps.– add quantitative extensions– recovery as part of quality of service (levels?)– semiautomatic tool / toolkitBTW: abstraction is no panacea! [Massalin, Shrikumar]

other directions– data-based applications as utility services

• Heterogeneity, Autonomy, Distribution -- Robustness?

• “Quality of Data”/ “Data Proxies”

54

related work

Transactions and Recovery theory and practice: – Bernstein et al., Wallace et al., Kuo (ARIES)– Gray and Reuter, Cabrera et al., Mohan et al.

Advanced Transaction Models– Chrysanthis and Ramamritham (ACTA)– García-Molina (Sagas)– Elmagarmid (ed.); Jajodia and Kerschberg

(eds.)

55

related work (ctd.)

Electronic Commerce– Tygar, Schuldt et al.

Recovery beyond databases– Lomet et al. (applications)– Kamath, Casati et al. (workflows)– Alonso and Korth, Barbará (mobile sys.

surveys)– Chrysanthis et al., Pradhan et al., Madria and

Bhargava, Yao et al. (mobile systems)