Ch13: Concurrency Control Techniques

Algorithm 17.1

1. Looks at only readItem(X) and write_Item(X) operations 2. Constructs a precedence graph (serialization graph) (a graph with directed edges) 3. An edge is created from Ti to Tj if one of the operations in Ti appears before a conflicting operation in Tj (RW, WR, WW)

Rules for Binary Locking

1. T must issue the operation lock(x) before any read(x) or write(x) operations are performed in T. 2. T must issues the operation unlock(x) after all read(x) and write(x) operations are completed in T 3. T will not issue lock(x) operation if it already holds the lock on item x 4. T will not issue an unlock(x) operation unless it already holds the lock on item x -At most one transaction can hold the lock on a particular item

Transaction schedule

A schedule (or history) S of n transactions T1, T2, ..., Tn that orders the operations of the transactions subject to the constraint that: -for each transaction Ti that participates in S -the operation of Ti in S must appear in the same order in which they occur in Ti

conflict serializable schedule

A schedule S, if it is conflict equivalent to some serial schedule S. -being serializable implies that the schedule is a correct schedule

Two phase locking protocol

A transaction where all locking operations (read_lock, write_lock) precede the first unlock operation. Schedule is guaranteed to be serializable. Growing (first) phase: new locks on items can be acquired but none can be released. shrinking (second) phase: existing locks can be released but no new locks can be acquired

test for serialibility

Algorithm 17.1

Victim selection algorithm

Avoid selecting transactions that have been running for a long time and that have performed many updates, and select transactions that have not made many changes

Deadlock Prevention

Conservative 2PHL (not practical). Requires a transaction to lock all the items it accesses before the transaction begins execution. If any of the item cannot be obtained, none of the items are locked. Then the transaction will try again at a later time

Deadlock detection

Deadlock only if the wait-for graph has cycle. DBMS needs to select a time to check for the deadlock. When a deadlock occurs, DBMS will choose some transaction causing the deadlock to abort.

serial schedule

For every transaction T participating in the schedule, all the operations of T are executed consecutively in the schedule (without interleaving, only one transaction active at once).

Time-out

If a transaction waits for a period longer than a system-defined timeout period, the system assumes that the transaction may be deadlocked an aborts it - regardless of whether a deadlock actually exists or not.

conflict equivalent

If the order of two schedules with any two conflicting operations is the same in both schedules

conflict

If two operations satisfy all three of the following conditions: 1.) They belong to different transactions 2.) They access the same item X 3.) At least one of the operations is a write_item(X)

Binary Locks

Lock(X): Data item X is locked in behalf of the requesting transaction. Unlock(X): Data item X is made available to all other transactions

Starvation

Occurs when a transaction cannot proceed for an indefinite period of time while other transactions in the system continue normally.

Deadlock

Occurs when each transaction T in a set of two or more transactions is waiting for some item that us locked by some other transaction T' in the set

Well-formed transaction

Required by databases that all transactions should be this. -It must lock the data item in an appropriate mode before it reads or writes to it -If the data item is already locked by another transaction in an incompatible mode, then T must wait until all incompatible locks held by other transactions have been released. -It must not try to unlock a free data item

equivalent serial schedule

Result equivalent, Serial schedule

Result equivalent

Two schedules that produce the same final state of the database (two different schedules may accidentally produce the same final state)

shared/exclusive locks

binary locking is too restrictive, so use this to allow several transactions to access the same item X if they all access x for reading purpose. three locking operations: read_lock(x), write_lock(x), and unlock(x)

Wait-for graph:

one node for each transaction that is currently executing, whenever Ti is waiting to lock an item X that is currently locked by a transaction Tj, a directed edge (Ti -> Tj) is created in the wait for graph

shared lock

read_lock(x), more than one transaction can apply share lock on x for reading its value.

exclusive lock

write_lock(x), only a single transaction exclusively holds the lock on the item