Chapter 4: Transaction Models

Transcription

1 Chapter 4: Transaction Models Handout #19 Overview simple transactions (flat) atomicity & spheres of control non-flat transactions CS346 - Transaction Processing Markus Breunig - 4 / 1 -

2 Atomic Actions atomicity: all-or-nothing actions unprotected protected real world real world actions idempotent testable how to make them atomic Flat Transactions simple only ones supported by most systems only one layer of control CS346 - Transaction Processing Markus Breunig - 4 / 2 -

3 Example: debit credit transaction - accounts table see textbook page do_debit_credit see textbook page transaction see textbook page 170 Main Table for D/C Transaction exec sql CREATE TABLE accounts ( Aid NUMERIC(9), Bid NUMERIC(9) FOREIGN KEY REFERENCES branches, Abalance NUMERIC(10), filler CHAR(48), PRIMARY KEY(Aid) ); CS346 - Transaction Processing Markus Breunig - 4 / 3 -

4 Subroutine that does work long DoDebitCredit (long Bid, long Tid, long Aid, long delta) { exec sql UPDATE accounts SET Abalance = Abalance + :delta WHERE Aid = :Aid; exec sql SELECT Abalance INTO : Abalance FROM accounts WHERE Aid = :Aid; exec sql UPDATE tellers SET Tbalance = Tbalance + :delta WHERE Tid = :Tid; exec sql UPDATE branches SET Bbalance = Bbalance + :delta WHERE Bid = :Bid; exec sql INSERT INTO history( Tid, Bid, Aid, delta, time) VALUES(: Tid, :Bid, :Aid, :delta, CURRENT); return( Abalance); } CS346 - Transaction Processing Markus Breunig - 4 / 4 -

5 The D/C Transaction DCApplication() { receive input message; exec sql BEGIN WORK; Abalance = DoDebitCredit(Bid, Tid, Aid, delta); if( Abalance < 0 && delta < 0 ) { exec sql ABORT WORK; } else { send output message exec sql COMMIT WORK; } } Discussion of D/C Transaction what does abort do? what about input message? notice style, not "defensive" real world actions? CS346 - Transaction Processing Markus Breunig - 4 / 5 -

6 Limitations of Flat Transactions Examples: Trip Planning Bulk Updates Transactions are long lots of work delays Transactions hold on to resources too long bad for performance Solution: break up transactions into smaller, related units T: T 1 T 2 T 3 if T 2 is reservation that fails: need to cancel T 1 reservation if T 2 is account update and system fails: How do we know where to pick up work? CS346 - Transaction Processing Markus Breunig - 4 / 6 -

7 2 nd important reason want to use transaction programming style BT... BT... if cond rollback... ET... ET CS346 - Transaction Processing Markus Breunig - 4 / 7 -

8 Extensions to Flat Transactions savepoints chained transactions nested transactions distributed transactions multi level transactions sagas... CS346 - Transaction Processing Markus Breunig - 4 / 8 -

9 Example to Illustrate Issues build nested transactions facility to support example above Issue #1: Visibility main procedure foo(a,b) BT BT access Z b = val... Z = val call foo(a,b) ET access b access Z... ET can main see b? Z? can others see Z after foo committs? (e.g. lock inheritance,...) CS346 - Transaction Processing Markus Breunig - 4 / 9 -

10 Issue #2: Abort Dependencies if foo rolls back, does main rollback? if main rolls back, does foo rollback? Issue #3: Commit Dependencies foo can only commit if main commits Issue #4: Execution Control how many subtransactions started? Do they communicate? Examples: concurrent subtransactions triggered subtransactions CS346 - Transaction Processing Markus Breunig - 4 / 10 -

11 Issue #5: New Commands Examples: rollback everything rollback just me CS346 - Transaction Processing Markus Breunig - 4 / 11 -

12 Sagas (simplified) as Another Example Π: T 1 T 2 T 3 Visibility: T i commits its changes visible to all T i is real ACID Transactions Π is not ACID! Abort: if T i rollsback, then run compensating transactions for T 1, T 2,..., T i-1 Commit: T i can only commit, if T i-1 committed Execution: saga is a list of programs P 1, P 2,..., P n executed in sequence if system fails during P i, it will be restarted at P i Commands: define saga = {P 1,..., P n } define compensation C i P i CS346 - Transaction Processing Markus Breunig - 4 / 12 -

13 Survey of Transaction Models flat transactions with savepoints chained transactions nested transactions distributed transactions multi-level transactions sagas CS346 - Transaction Processing Markus Breunig - 4 / 13 -

14 Savepoints Motivation: simplify programming can selectively undo work prevent loss of work (persistent savepoints) manual restart of application automatic restart (but what about programm volatile state?) Commands: save_work commit subtransaction and give a name to current state rollback_work(id) restore state at save_work id. [see textbook Figures 4.8] CS346 - Transaction Processing Markus Breunig - 4 / 14 -

15 Comment: transaction with savepoints is a type of nested transaction T save_work end subtrans begin subtrans save_work end subtrans begin subtrans CS346 - Transaction Processing Markus Breunig - 4 / 15 -

16 Chained Transactions sequence of independent transactions Π: T 1 T 2 T 3 T 4 context kept open between transactions (optimization) rollback possible only for the current T i (as opposed to savepoints) if system fails, chain should be restarted (or not?) if transaction aborts, chain should not be restarted (or?) solution? CS346 - Transaction Processing Markus Breunig - 4 / 16 -

17 Nested Transactions is child of Π T 1 T 2 T 2,1 T 2,2 T 2,3 T 2,2,1 changes by subtransaction visible to parent (upon commit of child), not visible to siblings rollback of (subtransaction) rollback of all children real commit when root commits subtransactions are ACI but not D [see textbook page 196, Figure 4.12] CS346 - Transaction Processing Markus Breunig - 4 / 17 -

18 Nested Transactions Locking - one way assume parent NOT active when children running (i.e. not parallelism) Transaction Ids i 1 i 1.i 2 i 1.i 2.i 3 i 1.i 2.i 4 i 1.i 2.i 4.i 5 id(t 1 ) = i 1.i 2.i 3...i n id(t 2 ) = j 1.j 2.j 3...j m T 1 T 2 T1 ancestor of T 2 n<m and i 1 =j 1 and... and i n = j n CS346 - Transaction Processing Markus Breunig - 4 / 18 -

19 Rules T 1 starts subtransaction T 2 id(t 2 ) = id(t 1 ).newid generate begin T 2 log record T 2 locks A in mode M 2 where a lock on A is held by T 1 in mode M 1 if M 1 and M 2 compatible grant if T 1 ancestor of T 2 grant CS346 - Transaction Processing Markus Breunig - 4 / 19 -

20 Example T 1 Lock A T 1 Lock A T 2 T 3 Lock A T 2 T 3 Initally T 2 requests A T 1 Lock A T 1 Lock A Lock A T 2 T 3 Wait A T T 2 3 T 3 requests A T 2 commit Lock A when T 2 updates A: generate log record (undo/redo) using id(t 2 ) as trid. CS346 - Transaction Processing Markus Breunig - 4 / 20 -

21 when T 2 commits write commit T 2 log record inherit locks to direct parent when root commits (id(root) = i 1 ) write commit i 1 log record release all locks held by transactions with id i 1.* when T 2 aborts (id(t 2 ) = i 1.i 2 ) write abort i 1.i 2 log record rollback all actions with id i 1.i 2.* release all locks held by transactions with id i 1.i 2.* recovery from a crash only consider abort/commit status of root transaction consider all i 1.* actions part of it more complicated orphan problem CS346 - Transaction Processing Markus Breunig - 4 / 21 -

22 Distributed Transactions just a flat transaction executed at several sites Site 1 Site 2 Π Π T 1 T 2 T 1, T 2 changes visible to each other T 1, T 2 commit/abort together CS346 - Transaction Processing Markus Breunig - 4 / 22 -

23 Multi-Level Transactions Example: a page with records Directory: [1, ], [2, ], [3, ] Record 1 Record 2 Record 3 Operations: Lookup(i) Insert(i) Delete(i) Compact Page CS346 - Transaction Processing Markus Breunig - 4 / 23 -

24 With Conventional Transactions: Π:... insert(4,...)... commit hold locks others cannot access page but we could let others see page, except for logical record 4 Two Levels: (layered object implementation) Logical: set of records; insert, delete, find,... Physical: page with bits; modify directory pointers, compact,... Logical Actions Are Reversible without locking the page! insert delete delete insert modify write old value CS346 - Transaction Processing Markus Breunig - 4 / 24 -

25 So if we only look at logical level: perfectly conventional and flat transactions Π: a 1, a 2,..., a n BUT from system viewpoint: insert = nested subtransaction of Π. Upon commit, its changes visible to other transactions if Π aborts, need to run compensating subtransaction Π a 1 a 2 a 2-1 a 2-1 rules similar to sagas except that? CS346 - Transaction Processing Markus Breunig - 4 / 25 -

26 Sagas collection of independent transactions Π: T 1, T 2,..., T n acceptable outcomes: T 1, T 2,..., T n T 1, T 1-1 T 1, T 2, T 2-1, T semantic atomicity no real atomicity CS346 - Transaction Processing Markus Breunig - 4 / 26 -

27 Saga Locking & Recovery concurrency control: each step independent recovery: at step commit: write commit record with link to previous step code name for compensation parameters for compensation at end of saga: write end saga commit record abort saga: execute compensation actions recovery from crash: execute compensation actions CS346 - Transaction Processing Markus Breunig - 4 / 27 -

28 Summary Flat Transaction Model limitations Other Models main distinction: how subtransactions interact CS346 - Transaction Processing Markus Breunig - 4 / 28 -