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