CPSC-608 Database Systems Fall 2018 Instructor: Jianer Chen Office: HRBB 315C Phone: 845-4259 Email: chen@cse.tamu.edu Notes #38

Tranactions What can affect transaction ACID? Atomicity: either all steps of a transaction happen, or none happen Consistency: a transaction transforms a consistent DB into a consistent DB Isolation: execution of a transaction is isolated from that of other transactions Durability: if a transaction commits, its effects persist. Database T1 …… Tn What can affect transaction ACID? Accident system failures may destroy Atomicity and Durability, thus Consistency; Concurrent executions of transactions (which is highly desired) may affect Isolation, thus Consistency.

DBMS Graduate Database lock table DDL language DDL complier file administrator DDL complier lock table DDL language file manager logging & recovery concurrency control transaction manager database programmer index/file manager buffer manager query execution engine DML complier main memory buffers DML (query) language secondary storage (disks) DBMS Graduate Database

Containment Relations Serializable schedules 2PL serial Conflict-serializable schedules Serializable schedule: equivalent to a serial schedule Conflict-serializable schedule: can be swapped into a serial schedule 2PL: transactions locks before any unlock. Serial schedule: transactions are executed one after the other

Beyond the simple 2PL protocol, it is all a matter of improving performance and allowing more concurrency …….

Recall our study on conflict-serializability Read and write by two transactions T1, T2: … r1(A)r2(B) … swap? … r1(A)w2(B) … … w1(A)r2(B) … … w1(A)w2(B) … √ √ √ √ … r1(A)r2(A) … swap? … r1(A)w2(A) … … w1(A)r2(A) … … w1(A)w2(A) … √

Recall our study on conflict-serializability Read and write by two transactions T1, T2: swap? √ swap? √ … r1(A)r2(B) … … w1(A)r2(B) … swap? √ swap? √ … r1(A)w2(B) … … w1(A)w2(B) … … r1(A)r2(A) … swap? … r1(A)w2(A) … … w1(A)r2(A) … … w1(A)w2(A) … √

Recall our study on conflict-serializability Read and write by two transactions T1, T2: Concurrent reads on the same element do not conflict. Thus, locking by a read that prevents others from reading discourages concurrency. swap? √ swap? √ … r1(A)r2(B) … … w1(A)r2(B) … swap? √ swap? √ … r1(A)w2(B) … … w1(A)w2(B) … … r1(A)r2(A) … swap? … r1(A)w2(A) … … w1(A)r2(A) … … w1(A)w2(A) … √

However, write conflicts with any other actions Recall our study on conflict-serializability Read and write by two transactions T1, T2: Concurrent reads on the same element do not conflict. Thus, locking by a read that prevents others from reading discourages concurrency. swap? √ swap? √ … r1(A)r2(B) … … w1(A)r2(B) … swap? √ swap? √ … r1(A)w2(B) … … w1(A)w2(B) … … r1(A)r2(A) … swap? … r1(A)w2(A) … … w1(A)r2(A) … … w1(A)w2(A) … √ However, write conflicts with any other actions

Thus, We may have two different kinds of locks on elements:

Thus, We may have two different kinds of locks on elements: Read-lock (shared-lock slk(A)) by Tk on A: friendly to reads, but block writes Write-lock (exclusive-lock xlk(A)) by Tk on A: block any other actions.

Thus, We may have two different kinds of locks on elements: Read-lock (shared-lock slk(A)) by Tk on A: friendly to reads, but block writes Write-lock (exclusive-lock xlk(A)) by Tk on A: block any other actions. Examples: S = ...... sl1(A)r1(A)sl2(A) r1(A) xl1(A) ……

does not block T2 because sl1(A) is friendly to sl2(A) Thus, We may have two different kinds of locks on elements: Read-lock (shared-lock slk(A)) by Tk on A: friendly to reads, but block writes Write-lock (exclusive-lock xlk(A)) by Tk on A: block any other actions. Examples: S = ...... sl1(A)r1(A)sl2(A) r1(A) xl1(A) …… does not block T2 because sl1(A) is friendly to sl2(A)

Thus, We may have two different kinds of locks on elements: Read-lock (shared-lock slk(A)) by Tk on A: friendly to reads, but block writes Write-lock (exclusive-lock xlk(A)) by Tk on A: block any other actions. Examples: S = ...... sl1(A)r1(A)sl2(A) r1(A) xl1(A) …… does not block T2 because sl1(A) is friendly to sl2(A) block T1 because sl2(A) is exclusive of xl1(A).

Some details Using compatibility matrix to represent lock relations: Lock requested shared exclusive YES NO Lock held

Some details Using compatibility matrix to represent lock relations: 2. What if a transaction needs to read and write on an element? Lock requested shared exclusive YES NO Lock held

Some details Using compatibility matrix to represent lock relations: 2. What if a transaction needs to read and write on an element? Option 1. An exclusive lock allows both read and write: T = ... xl1(A) … r1(A) … w1(A) … u(A) … Lock requested shared exclusive YES NO Lock held

Some details Using compatibility matrix to represent lock relations: 2. What if a transaction needs to read and write on an element? Option 1. An exclusive lock allows both read and write: T = ... xl1(A) … r1(A) … w1(A) … u(A) … Option 2. A transaction can exclusively lock an element shared-locked by itself: T = ... sl1(A) … r1(A) … xl1(A) … w1(A) … u(A) … Lock requested shared exclusive YES NO Lock held

Some details Using compatibility matrix to represent lock relations: 2. What if a transaction needs to read and write on an element? Option 1. An exclusive lock allows both read and write: T = ... xl1(A) … r1(A) … w1(A) … u(A) … Option 2. A transaction can exclusively lock an element shared-locked by itself: T = ... sl1(A) … r1(A) … xl1(A) … w1(A) … u(A) … How to unlock a shared/exclusive lock? Lock requested shared exclusive YES NO Lock held

Some details Using compatibility matrix to represent lock relations: 2. What if a transaction needs to read and write on an element? Option 1. An exclusive lock allows both read and write: T = ... xl1(A) … r1(A) … w1(A) … u(A) … Option 2. A transaction can exclusively lock an element shared-locked by itself: T = ... sl1(A) … r1(A) … xl1(A) … w1(A) … u(A) … How to unlock a shared/exclusive lock? Can have either different unlocks for different locks, or a single lock for all locks (our discussion will use a single unlock). Lock requested shared exclusive YES NO Lock held

How Do Shared/Exclusive Locks Affect Serializability? YES NO How Do Shared/Exclusive Locks Affect Serializability? Theorem. 2PL still works for shared/exclusive locks.

How Do Shared/Exclusive Locks Affect Serializability? YES NO How Do Shared/Exclusive Locks Affect Serializability? Theorem. 2PL still works for shared/exclusive locks. Proof. Let S be a 2PL schedule in which transaction T1 starts its unlocks the latest. Let a be any action of T1. Suppose that there is an action a’ by another transactions Tk that conflicts a and appears after a in the schedule S. Thus, S = …… a …… a’ …… Since a and a’ conflict, they are on the same element A. Both T1 and Tk need to lock A before their corresponding actions a and a’ can be executed. Since a appears in S before a’, T1 must lock A before Tk does. So the schedule S looks like S = … l1(A) … a … lk (A) … a’… Tk cannot lock A before T1 unlocks A. So S = … l1(A) … a … u1(A) … lk (A) … a’… . Since S is 2PL, the first unlock of Tk must appear after lk (A) , thus after u1(A). But this contradicts the assumption that T1 starts its unlock the latest. Thus, in the schedule S, there is no action by transactions other than T1 that conflicts an action of T1 and appears after the conflicting action of T1. So, we can swap the actions in S to move all actions of T1 to the tail of the schedule. The new schedule has a form S1 = α1T1. The new schedule S1 is equivalent to S. Using the same argument, we can move all actions of the transaction T2 that started its unlocks the second latest, to construct a schedule of the form S2 = α2T2T1 that is also equivalent to S. Repeating this process, we will eventually get a serial schedule that is equivalent to S. ■

How Do Shared/Exclusive Locks Affect Serializability? YES NO How Do Shared/Exclusive Locks Affect Serializability? Theorem. 2PL still works for shared/exclusive locks. Proof. Let S be a 2PL schedule in which transaction T1 starts its unlocks the latest. Let a be any action of T1. Suppose that there is an action a’ by another transactions Tk that conflicts a and appears after a in the schedule S. Thus, S = …… a …… a’ …… Since a and a’ conflict, they are on the same element A. Both T1 and Tk need to lock A before their corresponding actions a and a’ can be executed. Since a appears in S before a’, T1 must lock A before Tk does. So the schedule S looks like S = … l1(A) … a … lk (A) … a’… Tk cannot lock A before T1 unlocks A. So S = … l1(A) … a … u1(A) … lk (A) … a’… . Since S is 2PL, the first unlock of Tk must appear after lk (A) , thus after u1(A). But this contradicts the assumption that T1 starts its unlock the latest. Thus, in the schedule S, there is no action by transactions other than T1 that conflicts an action of T1 and appears after the conflicting action of T1. So, we can swap the actions in S to move all actions of T1 to the tail of the schedule. The new schedule has a form S1 = α1T1. The new schedule S1 is equivalent to S. Using the same argument, we can move all actions of the transaction T2 that started its unlocks the second latest, to construct a schedule of the form S2 = α2T2T1 that is also equivalent to S. Repeating this process, we will eventually get a serial schedule that is equivalent to S. ■ and at least one is write. Thus, the locks used by a and a’ are exclusive

Since l1(A) and lk (A) are exclusive, shared exclusive YES NO How Do Shared/Exclusive Locks Affect Serializability? Theorem. 2PL still works for shared/exclusive locks. Proof. Let S be a 2PL schedule in which transaction T1 starts its unlocks the latest. Let a be any action of T1. Suppose that there is an action a’ by another transactions Tk that conflicts a and appears after a in the schedule S. Thus, S = …… a …… a’ …… Since a and a’ conflict, they are on the same element A. Both T1 and Tk need to lock A before their corresponding actions a and a’ can be executed. Since a appears in S before a’, T1 must lock A before Tk does. So the schedule S looks like S = … l1(A) … a … lk (A) … a’… Tk cannot lock A before T1 unlocks A. So S = … l1(A) … a … u1(A) … lk (A) … a’… . Since S is 2PL, the first unlock of Tk must appear after lk (A) , thus after u1(A). But this contradicts the assumption that T1 starts its unlock the latest. Thus, in the schedule S, there is no action by transactions other than T1 that conflicts an action of T1 and appears after the conflicting action of T1. So, we can swap the actions in S to move all actions of T1 to the tail of the schedule. The new schedule has a form S1 = α1T1. The new schedule S1 is equivalent to S. Using the same argument, we can move all actions of the transaction T2 that started its unlocks the second latest, to construct a schedule of the form S2 = α2T2T1 that is also equivalent to S. Repeating this process, we will eventually get a serial schedule that is equivalent to S. ■ and at least one is write. Thus, the locks used by a and a’ are exclusive Since l1(A) and lk (A) are exclusive,

Lock Types Beyond Shared/Exclusive Locks

Lock Types Beyond Shared/Exclusive Locks Increment lock (further encouragement of concurrency): Allowing sharing simple write locks (for writes that increase an element by a constant): wi(A): A ← A+20):

Lock Types Beyond Shared/Exclusive Locks Increment lock (further encouragement of concurrency): Allowing sharing simple write locks (for writes that increase an element by a constant): wi(A): A ← A+20): A=10 A=17 A=25 A=32 W1(A): A ← A+15 W1(A): A ← A+7

Lock Types Beyond Shared/Exclusive Locks Increment lock (further encouragement of concurrency): Allowing sharing simple write locks (for writes that increase an element by a constant): wi(A): A ← A+20): A=10 A=17 A=25 A=32 W1(A): A ← A+15 W1(A): A ← A+7 shared exclusive increment YES NO

Lock Types Beyond Shared/Exclusive Locks Increment lock (further encouragement of concurrency): Allowing sharing simple write locks (for writes that increase an element by a constant): wi(A): A ← A+20): A=10 A=17 A=25 A=32 W1(A): A ← A+15 W1(A): A ← A+7 shared exclusive increment YES NO Update lock (reducing deadlocks): Shared locks are probably too flexible that may cause deadlocks. Update locks make it a bit more difficult.

Lock Types Beyond Shared/Exclusive Locks Increment lock (further encouragement of concurrency): Allowing sharing simple write locks (for writes that increase an element by a constant): wi(A): A ← A+20): A=10 A=17 A=25 A=32 W1(A): A ← A+15 W1(A): A ← A+7 shared exclusive increment YES NO Update lock (reducing deadlocks): Shared locks are probably too flexible that may cause deadlocks. Update locks make it a bit more difficult. T1: T2: sl1(A); sl2(A); xl1(A); xl2(A);

Lock Types Beyond Shared/Exclusive Locks Increment lock (further encouragement of concurrency): Allowing sharing simple write locks (for writes that increase an element by a constant): wi(A): A ← A+20): A=10 A=17 A=25 A=32 W1(A): A ← A+15 W1(A): A ← A+7 shared exclusive increment YES NO Update lock (reducing deadlocks): Shared locks are probably too flexible that may cause deadlocks. Update locks make it a bit more difficult. T1: T2: sl1(A); sl2(A); xl1(A); xl2(A); allowed allowed

Lock Types Beyond Shared/Exclusive Locks Increment lock (further encouragement of concurrency): Allowing sharing simple write locks (for writes that increase an element by a constant): wi(A): A ← A+20): A=10 A=17 A=25 A=32 W1(A): A ← A+15 W1(A): A ← A+7 shared exclusive increment YES NO Update lock (reducing deadlocks): Shared locks are probably too flexible that may cause deadlocks. Update locks make it a bit more difficult. T1: T2: sl1(A); sl2(A); xl1(A); xl2(A); allowed allowed blocked blocked Deadlock!

Lock Types Beyond Shared/Exclusive Locks Increment lock (further encouragement of concurrency): Allowing sharing simple write locks (for writes that increase an element by a constant): wi(A): A ← A+20): A=10 A=17 A=25 A=32 W1(A): A ← A+15 W1(A): A ← A+7 shared exclusive increment YES NO Update lock (reducing deadlocks): Shared locks are probably too flexible that may cause deadlocks. Update locks make it a bit more difficult. T1: T2: sl1(A); sl2(A); xl1(A); xl2(A);

Lock Types Beyond Shared/Exclusive Locks Increment lock (further encouragement of concurrency): Allowing sharing simple write locks (for writes that increase an element by a constant): wi(A): A ← A+20): A=10 A=17 A=25 A=32 W1(A): A ← A+15 W1(A): A ← A+7 shared exclusive increment YES NO Update lock (reducing deadlocks): Shared locks are probably too flexible that may cause deadlocks. Update locks make it a bit more difficult. T1: T2: ul1(A); ul2(A); xl1(A); sl2(A); A transaction can obtain an exclusive lock xl on A only if it already holds an update lock ul on A

Lock Types Beyond Shared/Exclusive Locks Increment lock (further encouragement of concurrency): Allowing sharing simple write locks (for writes that increase an element by a constant): wi(A): A ← A+20): A=10 A=17 A=25 A=32 W1(A): A ← A+15 W1(A): A ← A+7 shared exclusive increment YES NO Update lock (reducing deadlocks): Shared locks are probably too flexible that may cause deadlocks. Update locks make it a bit more difficult. T1: T2: ul1(A); ul2(A); xl1(A); sl2(A); shared exclusive update YES NO A transaction can obtain an exclusive lock xl on A only if it already holds an update lock ul on A

Lock Types Beyond Shared/Exclusive Locks Increment lock (further encouragement of concurrency): Allowing sharing simple write locks (for writes that increase an element by a constant): wi(A): A ← A+20): A=10 A=17 A=25 A=32 W1(A): A ← A+15 W1(A): A ← A+7 shared exclusive increment YES NO Update lock (reducing deadlocks): Shared locks are probably too flexible that may cause deadlocks. Update locks make it a bit more difficult. T1: T2: ul1(A); ul2(A); xl1(A); sl2(A); shared exclusive update YES NO A transaction can obtain an exclusive lock xl on A only if it already holds an update lock ul on A Will be blocked so a deadlock is avoided.

Lock Types Beyond Shared/Exclusive Locks Increment lock (further encouragement of concurrency): Allowing sharing simple write locks (for writes that increase an element by a constant): wi(A): A ← A+20): A=10 A=17 A=25 A=32 W1(A): A ← A+15 W1(A): A ← A+7 shared exclusive increment YES NO Update lock (reducing deadlocks): Shared locks are probably too flexible that may cause deadlocks. Update locks make it a bit more difficult. T1: T2: ul1(A); ul2(A); xl1(A); sl2(A); shared exclusive update YES NO A transaction can obtain an exclusive lock xl on A only if it already holds an update lock ul on A Cannot completely avoid deadlocks Will be blocked so a deadlock is avoided.

Lock Types Beyond Shared/Exclusive Locks Increment lock (further encouragement of concurrency): Allowing sharing simple write locks (for writes that increase an element by a constant): wi(A): A ← A+20): A=10 A=17 A=25 A=32 W1(A): A ← A+15 W1(A): A ← A+7 shared exclusive increment YES NO Update lock (reducing deadlocks): Shared locks are probably too flexible that may cause deadlocks. Update locks make it a bit more difficult. T1: T2: sl1(A); sl2(B); ul1(B); ul2(A); T1: T2: ul1(A); ul2(A); xl1(A); sl2(A); shared exclusive update YES NO A transaction can obtain an exclusive lock xl on A only if it already holds an update lock ul on A Cannot completely avoid deadlocks Deadlock! Will be blocked so a deadlock is avoided.

How Does Locking Work?

How Does Locking Work? Scheduler inserts lock actions for transactions.

How Does Locking Work? Scheduler inserts lock actions for transactions. Scheduler, part I DB lock table T1, T2, … read(A), write(B), … Scheduler, part II l(A), read(A), l(B), write(B), …

How Does Locking Work? Scheduler inserts lock actions for transactions. Lock table Scheduler, part I DB lock table T1, T2, … read(A), write(B), … Scheduler, part II l(A), read(A), l(B), write(B), …

How Does Locking Work? Scheduler inserts lock actions for transactions. Lock table Scheduler, part I DB lock table T1, T2, … read(A), write(B), … Scheduler, part II l(A), read(A), l(B), write(B), … A B ... lock info for A lock info for B h A lock table (a hash table, contains only locked elements)

How Does Locking Work? Scheduler inserts lock actions for transactions. Lock table Scheduler, part I DB lock table T1, T2, … read(A), write(B), … Scheduler, part II l(A), read(A), l(B), write(B), … A B ... lock info for A lock info for B h A group mode: U waiting: yes T1 S no T2 U T3 X yes  tran mode wait? next T-link lock table (a hash table, contains only locked elements)