Transaction Processing: Basics - Transactions • Transaction is execution of program that accesses DB • Basic operations: 1. read item(X): Read DB item X into program variable 2. write item(X): Write program variable into DB item X • Basic unit of transfer is disk block • Basic ops consist of lower-level atomic operations: { read item(X): 1. Find address of disk block containing X 2. Copy block into buffer if not in memory already 3. Copy data item from buffer to variable { write item(X): Write program variable into DB item X 1. Find address of disk block containing X 2. Copy block into buffer if not in memory already 3. Copy variable into appropriate location in buffer 4. Write buffer to disk • Sample transaction: read item(X) X = X + A write item(X) read item(Y) read item(X) Y = Y + X write item(Y) • Problems arise wrt concurrency and recovery 1 Transaction Processing: Basics - Concurrency Problems Lost Update T1 T2 r(X) X += A r(X) w(X) X += B w(X) Dirty Read T1 T2 r(X) X += A w(X) r(X) abort w(X) Incorrect Summary T1 T2 r(X) Sum = 0 X += A w(X) r(X) Sum += X r(Y) r(Y) Y += B w(Y) Sum += Y 2 Transaction Processing: Basics - Concurrency Problems 2 Non-repeatable Read T1 T2 r(X) r(Y) r(X) X += A w(X) r(Z) r(X) 3 Transaction Processing: Basics - Desirable Characteristics • ACID properties: 1. Atomicity { Transaction is atomic unit of DB processing { It executes in its entirety, or not at all 2. Consistency preservation Transaction takes DB from one consistent state to another 3. Isolation { Effects of transaction are invisible to other transactions until committed { Degrees of isolation: (a) 0: Does not overwrite dirty reads made by transactions of higher degree (b) 1: No lost updates (c) 2: No lost updates and no dirty reads (d) 3: (true isolation): Repeatable reads 4. Durability Once committed, changes cannot be lost 4 Transaction Processing: Basics - Recovery • To enforce consistency, system must insure that transactions either 1. Complete successfully, with all changes to DB permanently recorded 2. Have no effect on DB - any changes made are undone I.e., Either all of its actions have effect, or none of them have effect • Transaction (redefined): Atomic unit of DB work that is executed in its entirety or not at all • Types of transactions: { Read only { Read/write • Types of failure: { Local errors or exceptions detected by transaction - data not found, program condition not met { Transaction or system error - overflow, user-enforced abort, logical error { Concurrency error { System crash { Disk failure { Physical problems, catastrophes - disk not mounted, fire, theft • First 4 recoverable • Recovery Manager is module responsible for recovery • Following operations monitored by Recovery Manager: 1. Begin transaction 2. Read 3. Write 4. End transaction 5. Commit 6. Rollback (abort) 7. Undo 8. Redo 5 Transaction Processing: Basics - Recovery (2) • Execution of transaction can be represented by state diagram: • Partially committed state most interesting: { System checks whether transaction has interfered with other transactions { Checks if failure at this point would preclude recovery { If checks OK, commit • System log (journal) maintains record of transactions for recovery • Stored on disk, archived on tape • Types of entries: 1. [start trans; T ] 2. [write item; T; X; old; new] 3. [read item; T; X] 4. [commit; T ] 5. [abort; T ] • Commit point reached when 1. Transaction completed 2. Effects of all operations recorded in log • From a commit, assumed all transaction actions are permanent 6 Transaction Processing: Basics - Recovery (3) • On failure, { Only those transactions not yet committed need be rolled back { Committed transactions whose operations are not yet recorded in DB can be redone from log • Log written to disk when { Block is full { On commit (force-write) 7 Transaction Processing: Schedules - Intro • Schedule of transactions T1;T2; :::; Tn is an ordering of the operations of the Ti such that the order of the operations of Ti are relatively the same in the schedule. • Operations of interest: read (r), write (w), abort (a), commit (c) • Given 2 transactions 1. T1: r(x); x = x + a; w(x); 2. T2: r(X); x = x + b; w(x); 2 schedules would be 1. S1: r1(x); w1(x); c1; r2(x); w2(x); c2; 2. S2: r1(x); r2(x); w2(x); w1(x); c2; c1; • Conflicting operations are those that 1. Belong to different transactions 2. Access the same data item 3. One of which is a write In S1 (and S2), conflicting operations are r1(x) and w2(x), r2(x) and w1(x, and w1(x) and w2(x) • Complete schedule is one in which 1. Every transaction ends with an abort or commit 2. For any pair of conflicting operations, one must precede the other in the schedule • Complete schedule imposes no restrictions on order of non-conflicting opera- tions Imposes a partial ordering on operations • Since DB processing is dynamic, concept of complete schedule is an abstract ideal • Committed projection of schedule S (C(S)) is the set of operations belonging to committed transactions of S Is more practical concept than a complete schedule • Can classify schedules wrt to their recoverability and their serializability 8 Transaction Processing: Schedules - Recoverability • T2 reads from T1 if T2 reads data items written by T1 { T1 should not abort prior to T2's read { There is no T3 that writes the data item between T1's write and T2's read • Types of schedules wrt recoverability: 1. Recoverable schedule is one in which no transaction T2 commits until all the Ti that write data items that are read by T2 have committed (a) S1: r1(x); w1(x); c1; r2(x); w2(x); c2; (recoverable) (b) S2: r1(x); r2(x); w2(x); w1(x); c2; c1; (recoverable) (c) S3: r1(x); w1(x); r2(x); w2(x); c2; c1; (not recoverable) { For a recoverable schedule, no committed transaction will ever need to be rolled back 2. Schedule avoids cascading rollback if every one of its transactions reads only data items written by only committed transactions { Cascading rollback is situation in which T1 aborts, forcing T2 to rollback because it read a data item written by T1 (a) S3 above experiences cascading rollback if change c1 to a1 (b) S1 above avoids cascading rollback 3. Strict schedule is one in which transactions cannot read or write data items until the transaction that writes the data item has committed { Recovery is process of restoring 'before' images of data items (a) S1 above is strict 9 Transaction Processing: Schedules - Serializability • Serial schedule is one in which transactions are not interleaved { Is correct { Wastes CPU time • Non-serial schedule allows interleaving { Subject to concurrency problems • Serializable schedule of n transactions is equivalent to some serial schedule of those n transactions { n! possible serial schedules for n transactions { m! possible schedules for the m operations in those n transactions ∗ 2 disjoint sets of these m! schedules: 1. Those equivalent to at least one serial schedule 2. Those not equivalent to any serial schedule 10 Transaction Processing: Schedules - Types of Serializability Equivalence 1. Result equivalence • Schedules S1 and S2 are result equivalent if they produce the same result • Generally not meaningful • Example: { Transactions: (a) T1: r(x); x = x2; w(x); (b) T2: r(x); x− = 5; w(x); { Schedules (x = 3 initially): (a) S1: r1(x); x = x2; w1(x); r2(x); x− = 5; w2(x); (b) S2: r2(x); x− = 5; w2(x); r1(x); x = x2; w1(x); 2. Conflict equivalence • Schedules S1 and S2 are conflict equivalent if the order of any 2 conflicting operations is the same in each • If different orders, then they could produce different results { Transactions: (a) T1: r(x); (b) T2: r(x); w(x); { Schedules: (a) S1: r1(x); r2(x); w2(x); (b) S2: r2(x); w2(x); r1(x); (not conflict equiv to S1) (c) S3: r2(x); r1(x); w2(x); (conflict equiv to S1) • Schedule is conflict serializable if it is conflict equivalent to some serial schedule 11 Transaction Processing: Schedules - Types of Serializability Equivalence (2) • Conflict serializable schedule can have its operations reordered to obtain the equivalent serial schedule { Transactions: (a) T1: r(x); w(x); (b) T2: r(x); w(x); { Schedules: S1 S2 S3 T1 T2 T1 T2 T1 T2 r1(x) r2(x) r1(x) x += a x += b r2(x) w1(x) w2(x) x += a r2(x) r1(x) w1(x) x += b x += a x += b w2(x) w1(x) w2(x) { Transactions: (a) T1: r(x); w(x); r(y), w(y); (b) T2: r(x); r(z); w(x); (c) T3: r(x); r(z); w(y); { Schedules: S1 S2 T1 T2 T3 T1 T2 T3 r(x) r(x) w(x) r(x) r(x) r(x) r(y) w(x) r(z) r(z) w(x) r(z) r(x) r(y) r(z) w(y) w(y) w(y) w(y) w(x) 12 Transaction Processing: Schedules - Types of Serializability Equivalence (3) • To test for conflict serializability: (a) For each transaction Ti in S, create a graph node Ti (b) For each situation in S where Tj does a read(X) after Ti does a write(X), create an edge Ti ! Tj (c) For each situation in S where Tj does a write(X) after Ti does a read(X), create an edge Ti ! Tj (d) For each situation in S where Tj does a write(X) after Ti does a write(X), create an edge Ti ! Tj (e) S is serializable if the resulting graph contains no cycles • If S is serializable, equivalent serial schedule is one in which Ti precedes every Tj for which there is an edge Ti ! Tj in the graph 3.