ConcurrencyControl
CONTENT
 Definition
 Types of protocols
 Lock-Based Protocols
 Lock Conversions
 Deadlock
 Timestamp-Based Protocols
 Validation-Based Protocols
DEFINITION
In computer science, concurrency is a property of systems in which
several computations are executing simultaneously, and potentially
interacting with each other.
Concurrency Control is the working concept that is required for
controlling and managing the concurrent execution of database
operations and thus avoiding the inconsistencies in the database.
Concurrent access is relatively easy if all users are only reading
data, as there is no way that they can interfere with one another.
PURPOSE
To enforce Isolation (through mutual exclusion) among conflicting
transactions.
To preserve database consistency through consistency preserving
execution of transactions.
To resolve read-write and write-write conflicts.
Example: In concurrent execution environment if Ti conflicts with T2
over a data item A, then the existing concurrency control decides if
T1 or T2 should get the A and if the other transaction is rolled-back
or waits.
PROTOCOL
The concurrency control protocols ensure the atomicity, consistency,
isolation, durability and serializability of the concurrent execution of
the database transactions.
TYPES OF PROTOCOL
 Lock Based Concurrency Control Protocol
 Time Stamp Concurrency Control Protocol
 Validation Based Concurrency Control Protocol
LOCK-BASED PROTOCOL
A lock is a mechanism to control concurrent access to a data item.
Data items can be locked in two modes :
1.exclusive (X) mode. Data item can be both read as well as
written. X-lock is requested using lock-X instruction.
2.shared (S) mode. Data item can only be read. S-lock
is requested using lock-S instruction.
Lock requests are made to concurrency-control manager. Transaction
can proceed only after request is granted.
LOCK-BASED PROTOCOL
Lock-compatibility matrix
A transaction may be granted a lock on an item if the requested lock
is compatible with locks already held on the item by other
transactions
Any number of transactions can hold shared locks on an item,
• But if any transaction holds an exclusive on the item no other
transaction may hold any lock on the item.
If a lock cannot be granted, the requesting transaction is made to
wait till all incompatible locks held by other transactions have been
released. The lock is then granted.
LOCK-BASED PROTOCOL
Example of a transaction performing locking:
T2: lock-S(A);
read (A);
unlock(A);
lock-S(B);
read (B);
unlock(B);
display(A+B)
Locking as above is not sufficient to guarantee serializability — if A and B get
updated in-between the read of A and B, the displayed sum would be wrong.
A locking protocol is a set of rules followed by all transactions while requesting and
releasing locks. Locking protocols restrict the set of possible schedules.
TWO-PHASE LOCKING PROTOCOL


•
•

•
•

lock points
LOCK MANAGEMENT
Lock and unlock requests are handled by the lock manager
Lock table entry:
• Number of transactions currently holding a lock
• Type of lock held (shared or exclusive)
• Pointer to queue of lock requests
Locking and unlocking have to be atomic operations
Lock upgrade: transaction that holds a shared lock can be upgraded
to hold an exclusive lock
LOCK CONVERSIONS
Two-phase locking with lock conversions:
– First Phase:
• can acquire a lock-S on item
• can acquire a lock-X on item
• can convert a lock-S to a lock-X (upgrade)
– Second Phase:
• can release a lock-S
• can release a lock-X
• can convert a lock-X to a lock-S (downgrade)
This protocol assures serializability. But still relies on the programmer to
insert the various locking instructions.
DEADLOCKS
Deadlock: Cycle of transactions waiting for locks to be released by
each other.
Two ways of dealing with deadlocks:
• Deadlock prevention
• Deadlock detection
DEADLOCK PREVENTION
Assign priorities based on timestamps. Assume Ti wants a lock that Tj
holds. Two policies are possible:
• Wait-Die: It Ti has higher priority, Ti waits for Tj; otherwise Ti aborts
• Wound-wait: If Ti has higher priority, Tj aborts; otherwise Ti waits
If a transaction re-starts, make sure it has its original timestamp
DEADLOCK DETECTION
Create a waits-for graph:
• Nodes are transactions
• There is an edge from Ti to Tj if Ti is waiting for Tj to release a lock
Periodically check for cycles in the waits-for graph
DEADLOCK DETECTION
Example:
T1: S(A), R(A), S(B)
T2: X(B),W(B) X(C)
T3: S(C), R(C) X(A)
T4: X(B)
DEADLOCK RECOVERY
When deadlock is detected :
• Some transaction will have to rolled back (made a victim) to break deadlock.
Select that transaction as victim that will incur minimum cost.
Rollback -- determine how far to roll back transaction
• Total rollback: Abort the transaction and then restart it.
• More effective to roll back transaction only as far as necessary to break
deadlock.
Starvation happens if same transaction is always chosen as victim. Include the
number of rollbacks in the cost factor to avoid starvation
TIMESTAMP-BASED PROTOCOL
Each transaction is issued a timestamp when it enters the system. If an old
transaction Ti has time-stamp TS(Ti), a new transaction Tj is assigned time-stamp
TS(Tj) such that TS(Ti) <TS(Tj).
The protocol manages concurrent execution such that the time-stamps determine
the serializability order.
In order to assure such behavior, the protocol maintains for each data Q two
timestamp values:
• W-timestamp(Q) is the largest time-stamp of any transaction that executed
write(Q) successfully.
• R-timestamp(Q) is the largest time-stamp of any transaction that executed
read(Q) successfully.
TIMESTAMP-BASED PROTOCOL
The timestamp ordering protocol ensures that any conflicting read and write
operations are executed in timestamp order.
Suppose a transaction Ti issues a read(Q)
1. If TS(Ti)  W-timestamp(Q), then Ti needs to read a value of Q that was
already overwritten.
• Hence, the read operation is rejected, and Ti is rolled back.
2. If TS(Ti)  W-timestamp(Q), then the read operation is executed, and R-
timestamp(Q) is set to max(R-timestamp(Q), TS(Ti)).
TIMESTAMP-BASED PROTOCOL
Suppose that transaction Ti issues write(Q).
1. If TS(Ti) < R-timestamp(Q), then the value of Q that Ti is producing was needed
previously, and the system assumed that that value would never be produced.
• Hence, the write operation is rejected, and Ti is rolled back.
2. If TS(Ti) < W-timestamp(Q), then Ti is attempting to write an obsolete value of Q.
• Hence, this write operation is rejected, and Ti is rolled back.
3. Otherwise, the write operation is executed, and W-timestamp(Q) is set to TS(Ti).
VALIDATION BASED PROTOCOL
Validation phase is also known as optimistic concurrency control technique. In the
validation based protocol, the transaction is executed in the following three phases:
1.Read phase: In this phase, the transaction T is read and executed. It is used to read
the value of various data items and stores them in temporary local variables. It can
perform all the write operations on temporary variables without an update to the
actual database.
2.Validation phase: In this phase, the temporary variable value will be validated
against the actual data to see if it violates the serializability.
3.Write phase: If the validation of the transaction is validated, then the temporary
results are written to the database or system otherwise the transaction is rolled
back.
VALIDATION BASED PROTOCOL

•
•
•

•

•
•
THOMAS’ WRITE RULE
Modified version of the timestamp-ordering protocol in which obsolete write
operations may be ignored under certain circumstances.
When Ti attempts to write data item Q, if TS(Ti) < W-timestamp(Q), then Ti is
attempting to write an obsolete value of {Q}.
• Rather than rolling back Ti as the timestamp ordering protocol would have
done, this {write} operation can be ignored.
Otherwise this protocol is the same as the timestamp ordering protocol.
Thomas' Write Rule allows greater potential concurrency.
• Allows some view-serializable schedules that are not conflict-serializable.
MULTIVERSION SCHEMES

•
•




Concurrency Control.pptx

Concurrency Control.pptx

  • 1.
  • 2.
    CONTENT  Definition  Typesof protocols  Lock-Based Protocols  Lock Conversions  Deadlock  Timestamp-Based Protocols  Validation-Based Protocols
  • 3.
    DEFINITION In computer science,concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. Concurrency Control is the working concept that is required for controlling and managing the concurrent execution of database operations and thus avoiding the inconsistencies in the database. Concurrent access is relatively easy if all users are only reading data, as there is no way that they can interfere with one another.
  • 4.
    PURPOSE To enforce Isolation(through mutual exclusion) among conflicting transactions. To preserve database consistency through consistency preserving execution of transactions. To resolve read-write and write-write conflicts. Example: In concurrent execution environment if Ti conflicts with T2 over a data item A, then the existing concurrency control decides if T1 or T2 should get the A and if the other transaction is rolled-back or waits.
  • 5.
    PROTOCOL The concurrency controlprotocols ensure the atomicity, consistency, isolation, durability and serializability of the concurrent execution of the database transactions.
  • 6.
    TYPES OF PROTOCOL Lock Based Concurrency Control Protocol  Time Stamp Concurrency Control Protocol  Validation Based Concurrency Control Protocol
  • 7.
    LOCK-BASED PROTOCOL A lockis a mechanism to control concurrent access to a data item. Data items can be locked in two modes : 1.exclusive (X) mode. Data item can be both read as well as written. X-lock is requested using lock-X instruction. 2.shared (S) mode. Data item can only be read. S-lock is requested using lock-S instruction. Lock requests are made to concurrency-control manager. Transaction can proceed only after request is granted.
  • 8.
    LOCK-BASED PROTOCOL Lock-compatibility matrix Atransaction may be granted a lock on an item if the requested lock is compatible with locks already held on the item by other transactions Any number of transactions can hold shared locks on an item, • But if any transaction holds an exclusive on the item no other transaction may hold any lock on the item. If a lock cannot be granted, the requesting transaction is made to wait till all incompatible locks held by other transactions have been released. The lock is then granted.
  • 9.
    LOCK-BASED PROTOCOL Example ofa transaction performing locking: T2: lock-S(A); read (A); unlock(A); lock-S(B); read (B); unlock(B); display(A+B) Locking as above is not sufficient to guarantee serializability — if A and B get updated in-between the read of A and B, the displayed sum would be wrong. A locking protocol is a set of rules followed by all transactions while requesting and releasing locks. Locking protocols restrict the set of possible schedules.
  • 10.
  • 11.
    LOCK MANAGEMENT Lock andunlock requests are handled by the lock manager Lock table entry: • Number of transactions currently holding a lock • Type of lock held (shared or exclusive) • Pointer to queue of lock requests Locking and unlocking have to be atomic operations Lock upgrade: transaction that holds a shared lock can be upgraded to hold an exclusive lock
  • 12.
    LOCK CONVERSIONS Two-phase lockingwith lock conversions: – First Phase: • can acquire a lock-S on item • can acquire a lock-X on item • can convert a lock-S to a lock-X (upgrade) – Second Phase: • can release a lock-S • can release a lock-X • can convert a lock-X to a lock-S (downgrade) This protocol assures serializability. But still relies on the programmer to insert the various locking instructions.
  • 13.
    DEADLOCKS Deadlock: Cycle oftransactions waiting for locks to be released by each other. Two ways of dealing with deadlocks: • Deadlock prevention • Deadlock detection
  • 14.
    DEADLOCK PREVENTION Assign prioritiesbased on timestamps. Assume Ti wants a lock that Tj holds. Two policies are possible: • Wait-Die: It Ti has higher priority, Ti waits for Tj; otherwise Ti aborts • Wound-wait: If Ti has higher priority, Tj aborts; otherwise Ti waits If a transaction re-starts, make sure it has its original timestamp
  • 15.
    DEADLOCK DETECTION Create awaits-for graph: • Nodes are transactions • There is an edge from Ti to Tj if Ti is waiting for Tj to release a lock Periodically check for cycles in the waits-for graph
  • 16.
    DEADLOCK DETECTION Example: T1: S(A),R(A), S(B) T2: X(B),W(B) X(C) T3: S(C), R(C) X(A) T4: X(B)
  • 17.
    DEADLOCK RECOVERY When deadlockis detected : • Some transaction will have to rolled back (made a victim) to break deadlock. Select that transaction as victim that will incur minimum cost. Rollback -- determine how far to roll back transaction • Total rollback: Abort the transaction and then restart it. • More effective to roll back transaction only as far as necessary to break deadlock. Starvation happens if same transaction is always chosen as victim. Include the number of rollbacks in the cost factor to avoid starvation
  • 18.
    TIMESTAMP-BASED PROTOCOL Each transactionis issued a timestamp when it enters the system. If an old transaction Ti has time-stamp TS(Ti), a new transaction Tj is assigned time-stamp TS(Tj) such that TS(Ti) <TS(Tj). The protocol manages concurrent execution such that the time-stamps determine the serializability order. In order to assure such behavior, the protocol maintains for each data Q two timestamp values: • W-timestamp(Q) is the largest time-stamp of any transaction that executed write(Q) successfully. • R-timestamp(Q) is the largest time-stamp of any transaction that executed read(Q) successfully.
  • 19.
    TIMESTAMP-BASED PROTOCOL The timestampordering protocol ensures that any conflicting read and write operations are executed in timestamp order. Suppose a transaction Ti issues a read(Q) 1. If TS(Ti)  W-timestamp(Q), then Ti needs to read a value of Q that was already overwritten. • Hence, the read operation is rejected, and Ti is rolled back. 2. If TS(Ti)  W-timestamp(Q), then the read operation is executed, and R- timestamp(Q) is set to max(R-timestamp(Q), TS(Ti)).
  • 20.
    TIMESTAMP-BASED PROTOCOL Suppose thattransaction Ti issues write(Q). 1. If TS(Ti) < R-timestamp(Q), then the value of Q that Ti is producing was needed previously, and the system assumed that that value would never be produced. • Hence, the write operation is rejected, and Ti is rolled back. 2. If TS(Ti) < W-timestamp(Q), then Ti is attempting to write an obsolete value of Q. • Hence, this write operation is rejected, and Ti is rolled back. 3. Otherwise, the write operation is executed, and W-timestamp(Q) is set to TS(Ti).
  • 21.
    VALIDATION BASED PROTOCOL Validationphase is also known as optimistic concurrency control technique. In the validation based protocol, the transaction is executed in the following three phases: 1.Read phase: In this phase, the transaction T is read and executed. It is used to read the value of various data items and stores them in temporary local variables. It can perform all the write operations on temporary variables without an update to the actual database. 2.Validation phase: In this phase, the temporary variable value will be validated against the actual data to see if it violates the serializability. 3.Write phase: If the validation of the transaction is validated, then the temporary results are written to the database or system otherwise the transaction is rolled back.
  • 22.
  • 23.
    THOMAS’ WRITE RULE Modifiedversion of the timestamp-ordering protocol in which obsolete write operations may be ignored under certain circumstances. When Ti attempts to write data item Q, if TS(Ti) < W-timestamp(Q), then Ti is attempting to write an obsolete value of {Q}. • Rather than rolling back Ti as the timestamp ordering protocol would have done, this {write} operation can be ignored. Otherwise this protocol is the same as the timestamp ordering protocol. Thomas' Write Rule allows greater potential concurrency. • Allows some view-serializable schedules that are not conflict-serializable.
  • 24.