DBMS Unit 5
DBMS Unit 5
Concurrency control is the procedure in DBMS for managing simultaneous operations without conflicting
with each another. Concurrent access is quite easy if all users are just reading data. There is no way they
can interfere with one another. Though for any practical database, would have a mix of reading and
WRITE operations and hence the concurrency is a challenge.
Concurrency control is used to address such conflicts which mostly occur with a multi-user system. It
helps you to make sure that database transactions are performed concurrently without violating the data
integrity of respective databases.
Therefore, concurrency control is a most important element for the proper functioning of a system where
two or multiple database transactions that require access to the same data, are executed simultaneously.
1. Lost Update
Occurs when two transactions read the same data and then update it, resulting in one update being lost.
Example:
T1: READ(X), X = X + 100, WRITE(X)
T2: READ(X), X = X * 2, WRITE(X)
If T1 and T2 execute concurrently without control, one update may be lost.
2. Dirty Read
Occurs when a transaction reads data that has been modified by another transaction but not yet
committed.
Example:
T1: UPDATE account SET balance = balance - 500
T2: SELECT balance FROM account (reads uncommitted balance)
If T1 is rolled back, T2 would have used invalid data.
3. Non-repeatable Read
Occurs when a transaction reads the same data twice and gets different values due to another
transaction's update.
Example:
T1: SELECT balance FROM account
T2: UPDATE account SET balance = balance + 100
T1: SELECT balance FROM account (gets a different value)
4. Phantom Read
Occurs when a transaction re-executes a query and finds a different set of rows due to another
transaction's insert/delete.
Example:
T1: SELECT * FROM orders WHERE amount > 1000
T2: INSERT INTO orders VALUES (1050)
T1: SELECT * FROM orders WHERE amount > 1000 (new row appears)
Different concurrency control protocols offer different benefits between the amount of concurrency they
allow and the amount of overhead that they impose.
Lock-Based Protocols
Two Phase
Timestamp-Based Protocols
Validation-Based Protocols
Lock-based Protocols
A lock is a data variable which is associated with a data item. This lock signifies that operations that can
be performed on the data item. Locks help synchronize access to the database items by concurrent
transactions.
All lock requests are made to the concurrency-control manager. Transactions proceed only once the lock
request is granted.
Binary Locks: A Binary lock on a data item can either locked or unlocked states.
Shared/exclusive: This type of locking mechanism separates the locks based on their uses. If a lock is
acquired on a data item to perform a write operation, it is called an exclusive lock.
A shared lock is also called a Read-only lock. With the shared lock, the data item can be shared between
transactions. This is because you will never have permission to update data on the data item.
For example, consider a case where two transactions are reading the account balance of a person. The
database will let them read by placing a shared lock. However, if another transaction wants to update that
account's balance, shared lock prevent it until the reading process is over.
For example, when a transaction needs to update the account balance of a person. You can allows this
transaction by placing X lock on it. Therefore, when the second transaction wants to read or write,
exclusive lock prevent this operation.
Starvation
Starvation is the situation when a transaction needs to wait for an indefinite period to acquire a lock.
Deadlock - Deadlock refers to a specific situation where two or more processes are waiting for each
other to release a resource or more than two processes are waiting for the resource in a circular chain.
Two-Phase locking protocol which is also known as a 2PL protocol. It is also called P2L. In this type of
locking protocol, the transaction should acquire a lock after it releases one of its locks.
This locking protocol divides the execution phase of a transaction into three different parts.
In the first phase, when the transaction begins to execute, it requires permission for the locks it
needs.
The second part is where the transaction obtains all the locks. When a transaction releases its
first lock, the third phase starts.
In this third phase, the transaction cannot demand any new locks. Instead, it only releases the
acquired locks.
The Two-Phase Locking protocol allows each transaction to make a lock or unlock request in two steps:
Growing Phase: In this phase transaction may obtain locks but may not release any locks.
Shrinking Phase: In this phase, a transaction may release locks but not obtain any new lock
It is true that the 2PL protocol offers serializability. However, it does not ensure that deadlocks do not
happen.
In the above-given diagram, you can see that local and global deadlock detectors are searching for
deadlocks and solve them with resuming transactions to their initial states.
Strict-Two phase locking system is almost similar to 2PL. The only difference is that Strict-2PL never
releases a lock after using it. It holds all the locks until the commit point and releases all the locks at one
go when the process is over.
Timestamp-based Protocols
The timestamp-based algorithm uses a timestamp to serialize the execution of concurrent transactions.
This protocol ensures that every conflicting read and write operations are executed in timestamp order.
The protocol uses the System Time or Logical Count as a Timestamp.
The older transaction is always given priority in this method. It uses system time to determine the time
stamp of the transaction. This is the most commonly used concurrency protocol.
Lock-based protocols help you to manage the order between the conflicting transactions when they will
execute. Timestamp-based protocols manage conflicts as soon as an operation is created.
Example:
T1 has timestamp TS(T1) = 5, T2 has TS(T2) = 10
If T2 tries to write a data item last read by T1, the system checks timestamps to decide whether to allow
or abort T2.
Advantages:
Disadvantages:
This technique assumes that conflicts are rare and allows transactions to execute without restrictions.
Before committing, it checks for conflicts during the validation phase. If validation fails, the transaction is
rolled back.
Example:
T1 reads data X and Y, performs operations, then enters validation phase.
If no conflict is found with other concurrent transactions, it commits.
If a conflict is found, it rolls back.
4. Multiple Granularity
This technique allows transactions to lock data at different levels of granularity, such as database, file,
page, or tuple. It uses intention locks to manage these hierarchies effectively.
Example:
T1 locks a table (higher granularity), T2 wants to lock a row in the same table (lower granularity).
Intention locks (like IS, IX) are used to handle such requests safely.
In MVCC, multiple versions of data items are maintained to allow read and write operations to occur
concurrently. Readers access a snapshot of the data, ensuring they don’t block writers and vice versa.
This improves performance and isolation.
Example:
T1 reads version V1 of data item A.
T2 writes a new version V2 of A.
T1 continues using V1 without being blocked or affected by T2’s write.