Lecture 009

Concurrency Control

We assume no failures.

Composit Operations

Issue with Composite Operations

Issue with Composite Operations

There is issue with composite operation even we made individual operation thread-safe:

Want programmer to be able to specify that a set of operations should happen atomically.

A "transaction" either 1. commits: executes correctly 2. aborts: has no effect at all

ACID Properties:

Atomic Operation: Atomicity + Isolation

Transection could be nested.

Single Server Consistency

We need to acquire locks according to some consistent global order: If we have \{L_1, L_2, L_3, ..., L_n\} in the system, and we establish a total order on all L_i, then there is no deadlock.

Two Phrase Locking

Two types of locks:

Shared Exclusive
Shared Compatible Not
Exclusive Not Not

2-phase Locking: it has to look like a "mountain" but not a "mountain range". Once you decide to go down, don't go up.

2-phase Locking: it has to look like a "mountain" but not a "mountain range". Once you decide to go down, don't go up.

2-phase Locking (2PL): growing, shrinking

  1. acquire or escalate locks (from s-lock to x-lock) as needed (atomically or according to some total order)
  2. once you decide to release lock, you can no longer acquire locks anymore (because we can't acquire locks after the first release, we need to figure out all possible locks we need before release)

2-phase locking is good as long as we assume every transaction to commit instead of abort. A bad situration would be "cascading aborts" (later decision to aborts need to cause rollback on previous edits): 1. acquire lock for A 2. write data to A 3. release lock for A 4. decide to abort for some reason

In this case, since it released lock A where A contains partial data, other thread might read into this unstable state.

Strong Strict 2-phase Locking (SS2PL): we only release all locks at once after all operations finished

But there is one way to not lock all possible locks before hand: we just use a library who manages lock and tells us whether we have a deadlock. (Since above method will still be correct if we don't lock atomically or in total order, but might generate deadlock)

Distributed Transactions

Distributed Database: Partition databases across multiple machines for scalability

We require either all machines commit transection, or none.

One-phase Commit:

One-phase commit only works when the transactions in all database result to commit with no violation. This is because if one server decide to abort due to violation of some rules, it cannot tell other servers who find no violation on their own database to abort.

2-phase Commit:

  1. Coordinator send transaction request to all participants
  2. Participants figure out all state changes, if a transaction is not possible due to violation, vote ABORT, else vote OK to the coordinator
  3. Coordinator broadcast voting result to all participants: either COMMIT or ABORT (COMMIT if and only if all participants vote OK)
  4. Participants COMMIT or ABORT accordingly.

Performance of 2-phase commit

Performance of 2-phase commit

Properties of 2-phase commit:

blocked: transaction is aborted even though it should commit based on the data, due to failure.

2-phase commit (2PC) is a blocking protocol because it block if no one got decision.

For performance, in reality, since a transaction is very likely to succeed, every server will commit optimistically and rollback if necessary.

Note that with 2-phrase commit, it is still possible to have deadlock in a local machine (cyclic dependency of locks). In this case, a participant is unable to respond to voting request. We can handle it with timeout. If participants time out, then coordinator assumes ABORT vote from that participant and retry transaction again (be careful with livelock when retry).

There are other methods like 3PC, which has correctness issues in asynchronous networks.

Table of Content