CSE 344 Section 6

Transactions & Locking

July 25th, 2024

Announcements

• HW5 due tomorrow, Friday 7/26

Transactions

ACID

Atomic�Consistent�Isolated�Durable

Everything a concurrent database user wants…

How do ACID properties help us?

• Ensure that a transaction maintains database integrity
• ACID compliance matters to important databases ($$$)
• In this section: delve into the DB Internals required to guarantee ACID

Atomicity

What? “Atom” - a transaction is indivisible; data operations inside the transaction work in an all or nothing fashion

How? Transaction commit and rollback

Example: Transfer of funds from one account to another involves an atomic transaction that includes operations of debit and credit

Consistency

What? Only data operations that comply with database validity constraints are allowed.

Once a transaction is completed, it must not leave the database incomplete or inconsistent.

How? Enforcement of consistency rules upon data entry/updation

Example: A database having both first and last name fields will not accept if you enter only one of those - must enter both for the transaction to be complete

Isolation

What? The appearance of a transaction happening by itself irrespective of what other transactions are happening concurrently

How? User views the database that was present right before the view request is made and any further transactions that are in process after it are ignored

Example: A teller looking up a balance must be isolated from a concurrent transaction involving a withdrawal from the same account

Durability

What? Once a transaction is complete the information as changed will survive failures of any kind

How? Creation of data “mirrors”

Example: Trying to make an update that leads to a system failure should not tamper with any of the previous data and transactions

Txn Perspective

A database is a collection of "elements" that can be written to or read from.

Operation - A read or write to an element (later: or an insert or delete)

​

Example: What operation does the following SQL query contain?�SELECT cases FROM Country WHERE cname = ‘France’;

​

Txn Perspective

A database is a collection of "elements" that can be written to or read from.

Operation - A read or write to an element (later: or an insert or delete)

​

Example: What operation does the following SQL query contain?�SELECT cases FROM Country WHERE cname = ‘France’;

Answer: R(Country) or R(France), depending on whether the "element" is a table or a row (assuming cname is a key). Let's go with the finer-grained element.

Definitions

Operation -

Transaction -

Schedule -

Serial schedule -�

Serializable schedule - �

Definitions

Operation - read or write of an element (later: insert or delete)

Transaction - series of operations meant to have the ACID guarantees

Schedule - ordering of the operations of some txns

Serial schedule - schedule where each txn is executed one after another.� No interleaving

Serializable schedule - a schedule that is behaviorally equivalent � to a serial schedule

Practice - convert SQL to operations

Txn 1:

1a) x = SELECT cases FROM Country WHERE cname = ‘France’;

1b) x = x + 200;

1c) UPDATE Country SET cases = `x` WHERE cname = ‘France’;

​

Txn 2:

2a) y = SELECT cases FROM Country WHERE cname = ‘Spain’;

2b) y = y / 5;

2c) z = SELECT cases FROM Country WHERE cname = ‘France’;

2d) UPDATE Country SET cases = `y + z` WHERE cname = ‘France’;

Practice - convert SQL to operations

Txn 1:

1a) x = SELECT cases FROM Country WHERE cname = ‘France’;

1b) x = x + 200;

1c) UPDATE Country SET cases = `x` WHERE cname = ‘France’;

​

Txn 2:

2a) y = SELECT cases FROM Country WHERE cname = ‘Spain’;

2b) y = y / 5;

2c) z = SELECT cases FROM Country WHERE cname = ‘France’;

2d) UPDATE Country SET cases = `y + z` WHERE cname = ‘France’;

1a) R(France)

1b)

1c) W(France)

​

​

2a) R(Spain)

2b)

2c) R(France)

2d) W(France)

Conflict Serializability

Definitions

Non-conflicting swap - �

Conflicting swap -

Conflict serializable schedule - �

​

Definitions

Non-conflicting swap - a pair of adjacent operations in a schedule � that can be reversed without affecting the schedule's behavior

Conflicting swap - (any two ops in same txn), RW, WR, WW

Conflict serializable schedule - a schedule that can be transformed � into a serial schedule via a series of non-conflicting swaps

​

Conflict Serializability

Checking for conflict serializability -> precedence graph and cycle checking

Conflict Serializability

Checking for conflict serializability -> precedence graph and cycle checking

Serializability

“Conflict serializable” is a stronger constraint than “serializable”

I.e. Any schedule that is conflict serializable must be serializable.

​

​

Serializable

Conflict

Serializable

Easy to check

Not easy to check

Serializability

S1: w1(Y); w2(Y); w1(X); w2(X); w3(X)

S2: w1(Y); w2(Y); w2(X); w1(X); w3(X)

Are these serializable? Conflict serializable?

Serializability

S1: w1(Y); w2(Y); w1(X); w2(X); w3(X)

S2: w1(Y); w2(Y); w2(X); w1(X); w3(X)

Conflict Serializable

Serializable (but not conflict serializable)

Locking

Locking Overview

Remember - locking is for database internal implementation

• A way to provide the ACID guarantees
• Pessimistic concurrency control
• Assumes transaction executions will conflict
• Users of a database need only specify �BEGIN TRANSACTION … COMMIT / ROLLBACK
• ...and the isolation level...

Database Lock

Table Lock

Predicate Lock

Tuple Lock

Lock Granularity

SQLite!

Less Concurrency

More Concurrency

Binary Locks

2PL with Binary Locks

Lock growing phase

Lock shrinking phase

2PL vs. Strict 2PL

Invalid reads

Trickled unlock and transaction end

2PL vs. Strict 2PL

2PL:

• In every transaction, all lock requests must precede all unlock requests
• Ensures conflict serializability
• Might not be able to recover (Dirty Read: Read on some write that gets rolled back)
• Can result in deadlocks

Strict 2PL:

• Every lock for each transaction is held until commit or abort
• Ensures conflict serializability
• Recoverable as each transaction does not affect others until commit/abort
• Can result in deadlocks

3-Tiered Locking (Shared/Exclusive locks)

• X(A) - Exclusive lock on A
• No other transaction can read or write to A
• S(A) - Shared lock on A
• Other transactions can acquire a shared lock to A, only allows for reads
• If only one transaction holds a shared lock for A, �then it can upgrade to an exclusive lock
• U(A) - No lock on A (or think of it as Unlock)
• This transaction does not hold a lock on A
• If it had a shared lock, some other transactions might still have a lock for A

All the locks!

Worksheet