Transaction Management Overview CS542 Transaction Management Overview Professor Elke A. Rundensteiner

Integrity of data ? We would like data in our database to be “accurate” ( “correct” ) at all times. EMP How DBMS decides if data is consistent? Name White Green Gray Age 52 3421 1

Integrity constraints for data consistency Utilize predicates data must satisfy Examples: - x is key of relation R - x  y holds in R - Domain(x) = {Red, Blue, Green} - a is valid index for attribute x of R - no employee should make more than twice the average salary

Definitions: Consistent state: satisfies all constraints Consistent DB: DB in consistent state

Such constraints may not capture “full correctness” Example 1 : Transaction constraints When salary is updated, new salary > old salary When account record is deleted, balance = 0

Observation: DB cannot be consistent always Example: Constraint : a1 + a2 +…. an = TOT Action: Deposit $100 in a2: a2  a2 + 100 TOT  TOT + 100

Example: a1 + a2 +…. an = TOT (constraint) TOT  TOT + 100 Deposit $100 in a2: a2  a2 + 100 TOT  TOT + 100 a2 TOT . . . 50 150 150 . . . 1000 1000 1100

Transaction: a collection of actions that preserve consistency Consistent DB Consistent DB’ T

Transactions Concurrent execution of user programs is essential for good DBMS performance. Because disk accesses are frequent and slow, must keep CPU busy by working on several user programs concurrently. A user’s program may carry out many operations on data, but DBMS only concerned about what data is read/written from/to database. Transaction is DBMS’s abstract view of user program: a sequence of reads and writes.

Transaction ACID Properties Atomic Either all actions are carried out or none are. Not worry about incomplete transaction. Consistency DBMS assumes that the consistency holds for each transaction. User is responsible. Isolation Transactions are isolated, or protected, from effects of concurrently scheduling other transactions. Durability The effects of transaction persist if DBMS informs the user about successful execution.

Atomicity of Transactions A transaction is seen by DBMS as a series of actions. read/write database object. A transaction might : commit after completing all its actions, or could abort (aborted by DBMS) after executing some actions. Transactions are atomic: user can think of a transaction as always executing all its actions in one step, or not executing any actions at all. DBMS logs all actions so that it can undo actions of aborted transactions.

Concurrency in a DBMS Issues: Users submit transactions, and can think of each transaction as executing by itself. Concurrency : DBMS interleaves actions (reads/writes of DB objects) of various transactions. Each transaction must leave database in consistent state if DB is consistent when transaction begins. DBMS will enforce ICs declared in CREATE TABLE statements. Beyond this, DBMS does not understand semantics of data. Issues: Effect of interleaving transactions, and crashes.

Big assumption: If T starts with consistent state AND T executes in isolation  T leaves consistent state

Correctness (informally) If we stop running transaction(s), DB left consistent Each transaction sees a consistent DB

How can constraints be violated? Transaction bug DBMS bug Hardware failure e.g., disk crash alters balance of account Data sharing e.g.: T1: give 10% raise to programmers T2: change programmers  systems analysts Violations due to sharing (concurrency control)!

Concurrency Control T1 T2 … Tn DB (consistency constraints)

Example: T1: Read(A) T2: Read(A) A  A+100 A  A2 Write(A) Write(A) Read(B) Read(B) B  B+100 B  B2 Write(B) Write(B) Constraint: A=B

Why interleave operations? A schedule An ordering of operations inside one or more transactions over time Why interleave operations?

Schedule A A B 25 25 T1 T2 Read(A); A  A+100 125 Write(A); 25 25 125 250 250 250 T1 T2 Read(A); A  A+100 Write(A); Read(B); B  B+100; Write(B); Read(A);A  A2; Read(B);B  B2;

Schedule B A B 25 25 T1 T2 Read(A);A  A2; 50 Write(A); 25 25 50 150 150 150 T1 T2 Read(A);A  A2; Write(A); Read(B);B  B2; Write(B); Read(A); A  A+100 Read(B); B  B+100;

Serial Schedules ! Any serial schedule is “good”.

Interleave Transactions in a Schedule?

Schedule C A B 25 25 T1 T2 Read(A); A  A+100 125 Write(A); 25 25 125 250 250 250 T1 T2 Read(A); A  A+100 Write(A); Read(A);A  A2; Read(B); B  B+100; Write(B); Read(B);B  B2;

Schedule D A B 25 25 T1 T2 Read(A); A  A+100 125 Write(A); 25 25 125 250 50 150 250 150 T1 T2 Read(A); A  A+100 Write(A); Read(A);A  A2; Read(B);B  B2; Write(B); Read(B); B  B+100;

Schedule E A B 25 25 T1 T2’ Read(A); A  A+100 125 Write(A); Same as Schedule D but with new T2’ A B 25 25 125 25 125 125 T1 T2’ Read(A); A  A+100 Write(A); Read(A);A  A1; Read(B);B  B1; Write(B); Read(B); B  B+100;

What is a ‘good’ schedule?

Sc=r1(A)w1(A)r2(A)w2(A)r1(B)w1(B)r2(B)w2(B) We want : schedules that are “good” regardless of initial state and transaction semantics Hence we consider : Only order of read and writes Example: Sc=r1(A)w1(A)r2(A)w2(A)r1(B)w1(B)r2(B)w2(B)

Example: Sc=r1(A)w1(A)r2(A)w2(A)r1(B)w1(B)r2(B)w2(B) Sc’=r1(A)w1(A) r1(B)w1(B)r2(A)w2(A)r2(B)w2(B) T1 T2

Remember Schedule C Sc=r1(A)w1(A)r2(A)w2(A)r1(B)w1(B)r2(B)w2(B) T1  T2 T1  T2  no cycles  C is “equivalent” to a serial schedule, I.e., in this case (T1,T2).

Schedule D A B 25 25 T1 T2 Read(A); A  A+100 125 Write(A); 25 25 125 250 50 150 250 150 T1 T2 Read(A); A  A+100 Write(A); Read(A);A  A2; Read(B);B  B2; Write(B); Read(B); B  B+100;

Let’s look at schedule Sd: Sd=r1(A)w1(A)r2(A)w2(A) r2(B)w2(B)r1(B)w1(B) Sd=r1(A)w1(A) r1(B)w1(B)r2(A)w2(A)r2(B)w2(B) T1 T2

Or, let’s try for Sd: Sd=r1(A)w1(A)r2(A)w2(A) r2(B)w2(B)r1(B)w1(B) Sd=r2(A)w2(A)r2(B)w2(B) r1(A)w1(A)r1(B)w1(B) T2 T1

We cannot do the needed swaps for Sd: Sd=r1(A)w1(A)r2(A)w2(A) r2(B)w2(B)r1(B)w1(B) there seems to be no save way to transform Sd into an equivalent serial schedule !?!

For Schedule D: Sd=r1(A)w1(A)r2(A)w2(A) r2(B)w2(B)r1(B)w1(B) T1  T2 T2  T1 T1 T2

For Schedule D: Sd=r1(A)w1(A)r2(A)w2(A) r2(B)w2(B)r1(B)w1(B) T1  T2 T2  T1 T1 T2 Cycle in schedule D.

If cycle of dependencies between transactions: If T2  T1 and T1  T2 T1 T2 If cycle of dependencies between transactions: Sd cannot be rearranged into a serial schedule Sd is not “equivalent” to any serial schedule Sd thus is a “bad” schedule!

Algorithm Idea: Swap non-conflicting operation pairs to see if you can go to a serial schedule.

Summary : Review of Concepts Transaction: sequence of ri(x), wi(x) actions Conflicting actions (if on same resource): r1(A) w2(A) w1(A) w2(A) r1(A) w2(A) Schedule: represents chronological order in which actions are executed Serial schedule: no interleaving of actions or transactions