SlideShare a Scribd company logo
2
Most read
7
Most read
11
Most read
Concurrency Control
Techniques
UNIT-V
Concurrency Control
In a multiprogramming environment where multiple transactions can be executed
simultaneously, it is highly important to control the concurrency of transactions. We have
concurrency control protocols to ensure atomicity, isolation, and serializability of concurrent
transactions. Concurrency control protocols can be broadly divided into two categories −
• Lock based protocols
• Time stamp based protocols
Lock-based Protocols
Database systems equipped with lock-based protocols use a mechanism by which any
transaction cannot read or write data until it acquires an appropriate lock on it. Locks are of two
kinds –
• Binary Locks − A lock on a data item can be in two states; it is either locked or unlocked.
• Shared/exclusive − This type of locking mechanism differentiates the locks based on their uses.
If a lock is acquired on a data item to perform a write operation, it is an exclusive lock. Allowing
more than one transaction to write on the same data item would lead the database into an
inconsistent state. Read locks are shared because no data value is being changed.
Lock Protocols
There are four types of lock of protocol-
• Simplistic Lock Protocol
• Pre-claiming Lock Protocol
• Two-Phase Locking 2PL
• Strict Two Phase Locking
Simplistic Lock Protocol
Simplistic lock-based protocols allow transactions to obtain a lock on every object before a
'write' operation is performed. Transactions may unlock the data item after completing the
‘write’ operation.
Pre-claiming Lock Protocol
• Pre-claiming protocols evaluate their operations and
create a list of data items on which they need locks.
• Before initiating an execution, the transaction
requests the system for all the locks it needs
beforehand.
• If all the locks are granted, the transaction executes
and releases all the locks when all its operations are
over.
• If all the locks are not granted, the transaction rolls
back and waits until all the locks are granted.
Two-phase Locking 2PL
• This locking protocol divides the execution phase of a transaction into three parts.
• In the first part, when the transaction starts executing, it seeks permission for the locks it
requires.
• The second part is where the transaction acquires all the locks. As soon as the transaction
releases its first lock, the third phase starts.
• In third part, the transaction cannot demand any new locks; it only releases the acquired locks.
• Two-phase locking has two phases, one is growing, where all the locks are being acquired by
the transaction; and the second phase is shrinking, where the locks held by the transaction are
being released.
• To claim an exclusive (write) lock, a transaction must first acquire a shared (read) lock and then
upgrade it to an exclusive lock.
Strict Two-Phase Locking
• The first phase of Strict-2PL is same as 2PL. After acquiring all the locks in the first phase, the
transaction continues to execute normally.
• In contrast to 2PL, Strict-2PL does not release a lock after using it.
• Strict-2PL holds all the locks until the commit point and releases all the locks at a time.
Timestamp based Protocols
• Lock-based protocols manage the order between the conflicting pairs among transactions at the
time of execution, whereas timestamp-based protocols start working as soon as a transaction is
created.
• Every transaction has a timestamp associated with it, and the ordering is determined by the age
of the transaction.
• A transaction created at 0002 clock time would be older than all other transactions that come
after it. For example, any transaction 'y' entering the system at 0004 is two seconds younger and
the priority would be given to the older one.
• In addition, every data item is given the latest read and write-timestamp. This lets the system
know when the last ‘read and write’ operation was performed on the data item.
Timestamp Ordering Protocol
The timestamp-ordering protocol ensures serializability among transactions in their conflicting
read and write operations. This is the responsibility of the protocol system that the conflicting
pair of tasks should be executed according to the timestamp values of the transactions.
• The timestamp of transaction Ti is denoted as TS(Ti).
• Read time-stamp of data-item X is denoted by R-timestamp(X).
• Write time-stamp of data-item X is denoted by W-timestamp(X)
If a transaction Ti issues a read(X)
operation −
◦ If TS(Ti) < W-timestamp(X)
◦ Operation rejected. (TS(Ti) is a
younger transaction)
◦ If TS(Ti) >= W-timestamp(X)
◦ Operation executed. (TS(Ti) is an older
transaction)
◦ All data-item timestamps updated.
If a transaction Ti issues a write(X)
operation −
• If TS(Ti) < R-timestamp(X)
• Operation rejected.
• If TS(Ti) < W-timestamp(X)
• Operation rejected and Ti
rolled back. (Thomas Write Rule)
• Otherwise, operation executed.
Timestamp ordering protocol works as follows −
Multiple Granularity
Multiple Granularity is the hierarchically breaking up the database into portions which are
lockable and maintaining the track of what to be lock and how much to be lock so that it can be
decided very quickly either to lock a data item or to unlock a data item.
Recovery with Concurrent Transaction
Checkpoint
Keeping and maintaining logs in real time and in real environment may fill out all the memory
space available in the system. As time passes, the log file may grow too big to be handled at all.
Checkpoint is a mechanism where all the previous logs are removed from the system and stored
permanently in a storage disk. Checkpoint declares a point before which the DBMS was in
consistent state, and all the transactions were committed.
Recovery
When a system with concurrent transactions crashes and recovers, it behaves in the following
manner −
• The recovery system reads the logs backwards from the end to the last checkpoint.
• It maintains two lists, an undo-list and a redo-list.
• If the recovery system sees a log with <Tn, Start> and <Tn, Commit> or just <Tn, Commit>, it
puts the transaction in the redo-list.
• If the recovery system sees a log with <Tn, Start> but no commit or abort log found, it puts the
transaction in undo-list.
Transaction Processing in Distributed
Systems
A transaction is a logical unit of work constituted by one or more SQL statements executed by a
single user. A transaction begins with the user's first executable SQL statement and ends when it
is committed or rolled back by that user.
A remote transaction contains only statements that access a single remote node. A distributed
transaction contains statements that access more than one node.
SELECT * FROM scott.dept@sales.us.americas.acme_auto.com;
Remote Select SQL Statement
UPDATE scott.dept@mktng.us.americas.acme_auto.com SET loc = 'NEW YORK' WHERE deptno = 10;
Remote Update SQL Statement
Distributed SQL Statement
SELECT ename, dname FROM scott.emp e, scott.dept@sales.us.americas.acme_auto.com d WHERE e.deptno = d.deptno;
BEGIN
UPDATE scott.dept@sales.us.americas.acme_auto.com
SET loc = 'NEW YORK'
WHERE deptno = 10;
UPDATE scott.emp
SET deptno = 11
WHERE deptno = 10;
END;
COMMIT;
A distributed update statement modifies data on
two or more nodes.
A distributed update is possible using a PL/SQL
subprogram unit such as a procedure or trigger
that includes two or more remote updates that
access data on different nodes.
For example, the following PL/SQL program unit
updates tables on the local database and the
remote sales database:
Data Replication and Allocation
Replication is useful in in improving the availability of data.
This can improve availability remarkably because the system can continue to operate as long as
at least one site is up. It also improves performance of retrieval for global queries, because the
result of such a query can be obtained locally from any one site.
The disadvantage of full Replication is that it can slow down update operations drastically, since
a single logical update must be performed on every copy of the database to keep the copies
consistent.
THANKS

More Related Content

PPTX
deadlock handling
PPTX
Concurrency control!
PPTX
Recovery Techniques and Need of Recovery
PPT
Two phase commit protocol in dbms
PPTX
Global state recording in Distributed Systems
PPT
16. Concurrency Control in DBMS
PPTX
Deadlocks in operating system
deadlock handling
Concurrency control!
Recovery Techniques and Need of Recovery
Two phase commit protocol in dbms
Global state recording in Distributed Systems
16. Concurrency Control in DBMS
Deadlocks in operating system

What's hot (20)

PPTX
Dead Lock in operating system
PPTX
Database recovery
PPTX
Distributed Transactions(flat and nested) and Atomic Commit Protocols
PPT
2 PHASE COMMIT PROTOCOL
PPTX
Concurrency control
PPT
Distributed file systems dfs
PPTX
PPTX
2 phase locking protocol DBMS
PPTX
Deadlock ppt
PPTX
Concurrency control
PPTX
DISTRIBUTED COMPUTTING (snapshot).pptx
PPSX
ARIES Recovery Algorithms
DOCX
Concurrency Control Techniques
DOCX
Operating System Process Synchronization
PPTX
Operating system 24 mutex locks and semaphores
PPT
Distributed Deadlock Detection.ppt
PPT
Chapter 12 transactions and concurrency control
PPTX
Transaction management DBMS
PPTX
Timestamp based protocol
PPT
Deadlock
Dead Lock in operating system
Database recovery
Distributed Transactions(flat and nested) and Atomic Commit Protocols
2 PHASE COMMIT PROTOCOL
Concurrency control
Distributed file systems dfs
2 phase locking protocol DBMS
Deadlock ppt
Concurrency control
DISTRIBUTED COMPUTTING (snapshot).pptx
ARIES Recovery Algorithms
Concurrency Control Techniques
Operating System Process Synchronization
Operating system 24 mutex locks and semaphores
Distributed Deadlock Detection.ppt
Chapter 12 transactions and concurrency control
Transaction management DBMS
Timestamp based protocol
Deadlock
Ad

Similar to Concurrency Control (20)

PDF
Concurrency note.pdf
PPTX
Transaction management
PDF
Design & Development of an Advanced Database Management System Using Multiver...
PDF
F017213747
PDF
F017213747
PPTX
Concurrency control PPT
PPTX
DBMS Pravin concurrency control technique.pptx
PPTX
Unit 5 dbms
PPTX
Unit 4 Concurrency control.pptx dbms lovely
PPTX
Unit 4 Concurrency control.pptx dbms lovely
PPTX
DBMS Presentation.pptx
PDF
concurrencycontrol from power pint pdf a
PPTX
Concurrency control
PPTX
Concurrency Control in Distributed Systems.pptx
PDF
Transaction Management, Concurrency Control and Deadlocks.pdf
PPTX
Overview of Concurrency Control & Recovery in Distributed Databases
PPTX
DBMS Session 6 Transactions Management and Concurrency Control.pptx
PPTX
Vani dbms
PDF
PPT-concurrency Control database management system DBMS concurrent control (U...
PDF
Advanced Database Chapter 4.pdf shnsbxlajmndm woweosmkl m,xcnkl C NOOxcx xcbnxc
Concurrency note.pdf
Transaction management
Design & Development of an Advanced Database Management System Using Multiver...
F017213747
F017213747
Concurrency control PPT
DBMS Pravin concurrency control technique.pptx
Unit 5 dbms
Unit 4 Concurrency control.pptx dbms lovely
Unit 4 Concurrency control.pptx dbms lovely
DBMS Presentation.pptx
concurrencycontrol from power pint pdf a
Concurrency control
Concurrency Control in Distributed Systems.pptx
Transaction Management, Concurrency Control and Deadlocks.pdf
Overview of Concurrency Control & Recovery in Distributed Databases
DBMS Session 6 Transactions Management and Concurrency Control.pptx
Vani dbms
PPT-concurrency Control database management system DBMS concurrent control (U...
Advanced Database Chapter 4.pdf shnsbxlajmndm woweosmkl m,xcnkl C NOOxcx xcbnxc
Ad

More from Nishant Munjal (20)

PPTX
Database Management System
PPTX
Functions & Recursion
PPTX
Array, string and pointer
PPTX
Programming in C
PPTX
Introduction to computers
PPTX
Unix Administration
PPTX
Shell Programming Concept
PPTX
VI Editor
PPTX
Introduction to Unix
PPTX
Routing Techniques
PPTX
Asynchronous Transfer Mode
PPTX
Overview of Cloud Computing
PPTX
SQL Queries Information
PPTX
Database Design and Normalization Techniques
PPTX
Transaction Processing Concept
PPTX
Database Management System
PPTX
Relational Data Model Introduction
PPTX
Virtualization, A Concept Implementation of Cloud
PPTX
Technical education benchmarks
PPSX
Bluemix Introduction
Database Management System
Functions & Recursion
Array, string and pointer
Programming in C
Introduction to computers
Unix Administration
Shell Programming Concept
VI Editor
Introduction to Unix
Routing Techniques
Asynchronous Transfer Mode
Overview of Cloud Computing
SQL Queries Information
Database Design and Normalization Techniques
Transaction Processing Concept
Database Management System
Relational Data Model Introduction
Virtualization, A Concept Implementation of Cloud
Technical education benchmarks
Bluemix Introduction

Recently uploaded (20)

PPTX
Construction Project Organization Group 2.pptx
DOCX
ASol_English-Language-Literature-Set-1-27-02-2023-converted.docx
PDF
Structs to JSON How Go Powers REST APIs.pdf
PDF
PRIZ Academy - 9 Windows Thinking Where to Invest Today to Win Tomorrow.pdf
PPTX
Internet of Things (IOT) - A guide to understanding
PPTX
web development for engineering and engineering
PPTX
UNIT 4 Total Quality Management .pptx
PDF
Model Code of Practice - Construction Work - 21102022 .pdf
PPTX
Welding lecture in detail for understanding
PDF
PPT on Performance Review to get promotions
PPTX
OOP with Java - Java Introduction (Basics)
PDF
Embodied AI: Ushering in the Next Era of Intelligent Systems
PDF
July 2025 - Top 10 Read Articles in International Journal of Software Enginee...
PPTX
MCN 401 KTU-2019-PPE KITS-MODULE 2.pptx
PPTX
Strings in CPP - Strings in C++ are sequences of characters used to store and...
PDF
BMEC211 - INTRODUCTION TO MECHATRONICS-1.pdf
PDF
Operating System & Kernel Study Guide-1 - converted.pdf
PPTX
Infosys Presentation by1.Riyan Bagwan 2.Samadhan Naiknavare 3.Gaurav Shinde 4...
PPTX
Lecture Notes Electrical Wiring System Components
PPTX
CH1 Production IntroductoryConcepts.pptx
Construction Project Organization Group 2.pptx
ASol_English-Language-Literature-Set-1-27-02-2023-converted.docx
Structs to JSON How Go Powers REST APIs.pdf
PRIZ Academy - 9 Windows Thinking Where to Invest Today to Win Tomorrow.pdf
Internet of Things (IOT) - A guide to understanding
web development for engineering and engineering
UNIT 4 Total Quality Management .pptx
Model Code of Practice - Construction Work - 21102022 .pdf
Welding lecture in detail for understanding
PPT on Performance Review to get promotions
OOP with Java - Java Introduction (Basics)
Embodied AI: Ushering in the Next Era of Intelligent Systems
July 2025 - Top 10 Read Articles in International Journal of Software Enginee...
MCN 401 KTU-2019-PPE KITS-MODULE 2.pptx
Strings in CPP - Strings in C++ are sequences of characters used to store and...
BMEC211 - INTRODUCTION TO MECHATRONICS-1.pdf
Operating System & Kernel Study Guide-1 - converted.pdf
Infosys Presentation by1.Riyan Bagwan 2.Samadhan Naiknavare 3.Gaurav Shinde 4...
Lecture Notes Electrical Wiring System Components
CH1 Production IntroductoryConcepts.pptx

Concurrency Control

  • 2. Concurrency Control In a multiprogramming environment where multiple transactions can be executed simultaneously, it is highly important to control the concurrency of transactions. We have concurrency control protocols to ensure atomicity, isolation, and serializability of concurrent transactions. Concurrency control protocols can be broadly divided into two categories − • Lock based protocols • Time stamp based protocols
  • 3. Lock-based Protocols Database systems equipped with lock-based protocols use a mechanism by which any transaction cannot read or write data until it acquires an appropriate lock on it. Locks are of two kinds – • Binary Locks − A lock on a data item can be in two states; it is either locked or unlocked. • Shared/exclusive − This type of locking mechanism differentiates the locks based on their uses. If a lock is acquired on a data item to perform a write operation, it is an exclusive lock. Allowing more than one transaction to write on the same data item would lead the database into an inconsistent state. Read locks are shared because no data value is being changed.
  • 4. Lock Protocols There are four types of lock of protocol- • Simplistic Lock Protocol • Pre-claiming Lock Protocol • Two-Phase Locking 2PL • Strict Two Phase Locking
  • 5. Simplistic Lock Protocol Simplistic lock-based protocols allow transactions to obtain a lock on every object before a 'write' operation is performed. Transactions may unlock the data item after completing the ‘write’ operation.
  • 6. Pre-claiming Lock Protocol • Pre-claiming protocols evaluate their operations and create a list of data items on which they need locks. • Before initiating an execution, the transaction requests the system for all the locks it needs beforehand. • If all the locks are granted, the transaction executes and releases all the locks when all its operations are over. • If all the locks are not granted, the transaction rolls back and waits until all the locks are granted.
  • 7. Two-phase Locking 2PL • This locking protocol divides the execution phase of a transaction into three parts. • In the first part, when the transaction starts executing, it seeks permission for the locks it requires. • The second part is where the transaction acquires all the locks. As soon as the transaction releases its first lock, the third phase starts. • In third part, the transaction cannot demand any new locks; it only releases the acquired locks. • Two-phase locking has two phases, one is growing, where all the locks are being acquired by the transaction; and the second phase is shrinking, where the locks held by the transaction are being released. • To claim an exclusive (write) lock, a transaction must first acquire a shared (read) lock and then upgrade it to an exclusive lock.
  • 8. Strict Two-Phase Locking • The first phase of Strict-2PL is same as 2PL. After acquiring all the locks in the first phase, the transaction continues to execute normally. • In contrast to 2PL, Strict-2PL does not release a lock after using it. • Strict-2PL holds all the locks until the commit point and releases all the locks at a time.
  • 9. Timestamp based Protocols • Lock-based protocols manage the order between the conflicting pairs among transactions at the time of execution, whereas timestamp-based protocols start working as soon as a transaction is created. • Every transaction has a timestamp associated with it, and the ordering is determined by the age of the transaction. • A transaction created at 0002 clock time would be older than all other transactions that come after it. For example, any transaction 'y' entering the system at 0004 is two seconds younger and the priority would be given to the older one. • In addition, every data item is given the latest read and write-timestamp. This lets the system know when the last ‘read and write’ operation was performed on the data item.
  • 10. Timestamp Ordering Protocol The timestamp-ordering protocol ensures serializability among transactions in their conflicting read and write operations. This is the responsibility of the protocol system that the conflicting pair of tasks should be executed according to the timestamp values of the transactions. • The timestamp of transaction Ti is denoted as TS(Ti). • Read time-stamp of data-item X is denoted by R-timestamp(X). • Write time-stamp of data-item X is denoted by W-timestamp(X)
  • 11. If a transaction Ti issues a read(X) operation − ◦ If TS(Ti) < W-timestamp(X) ◦ Operation rejected. (TS(Ti) is a younger transaction) ◦ If TS(Ti) >= W-timestamp(X) ◦ Operation executed. (TS(Ti) is an older transaction) ◦ All data-item timestamps updated. If a transaction Ti issues a write(X) operation − • If TS(Ti) < R-timestamp(X) • Operation rejected. • If TS(Ti) < W-timestamp(X) • Operation rejected and Ti rolled back. (Thomas Write Rule) • Otherwise, operation executed. Timestamp ordering protocol works as follows −
  • 12. Multiple Granularity Multiple Granularity is the hierarchically breaking up the database into portions which are lockable and maintaining the track of what to be lock and how much to be lock so that it can be decided very quickly either to lock a data item or to unlock a data item.
  • 13. Recovery with Concurrent Transaction Checkpoint Keeping and maintaining logs in real time and in real environment may fill out all the memory space available in the system. As time passes, the log file may grow too big to be handled at all. Checkpoint is a mechanism where all the previous logs are removed from the system and stored permanently in a storage disk. Checkpoint declares a point before which the DBMS was in consistent state, and all the transactions were committed. Recovery When a system with concurrent transactions crashes and recovers, it behaves in the following manner −
  • 14. • The recovery system reads the logs backwards from the end to the last checkpoint. • It maintains two lists, an undo-list and a redo-list. • If the recovery system sees a log with <Tn, Start> and <Tn, Commit> or just <Tn, Commit>, it puts the transaction in the redo-list. • If the recovery system sees a log with <Tn, Start> but no commit or abort log found, it puts the transaction in undo-list.
  • 15. Transaction Processing in Distributed Systems A transaction is a logical unit of work constituted by one or more SQL statements executed by a single user. A transaction begins with the user's first executable SQL statement and ends when it is committed or rolled back by that user. A remote transaction contains only statements that access a single remote node. A distributed transaction contains statements that access more than one node. SELECT * FROM scott.dept@sales.us.americas.acme_auto.com; Remote Select SQL Statement UPDATE scott.dept@mktng.us.americas.acme_auto.com SET loc = 'NEW YORK' WHERE deptno = 10; Remote Update SQL Statement
  • 16. Distributed SQL Statement SELECT ename, dname FROM scott.emp e, scott.dept@sales.us.americas.acme_auto.com d WHERE e.deptno = d.deptno; BEGIN UPDATE scott.dept@sales.us.americas.acme_auto.com SET loc = 'NEW YORK' WHERE deptno = 10; UPDATE scott.emp SET deptno = 11 WHERE deptno = 10; END; COMMIT; A distributed update statement modifies data on two or more nodes. A distributed update is possible using a PL/SQL subprogram unit such as a procedure or trigger that includes two or more remote updates that access data on different nodes. For example, the following PL/SQL program unit updates tables on the local database and the remote sales database:
  • 17. Data Replication and Allocation Replication is useful in in improving the availability of data. This can improve availability remarkably because the system can continue to operate as long as at least one site is up. It also improves performance of retrieval for global queries, because the result of such a query can be obtained locally from any one site. The disadvantage of full Replication is that it can slow down update operations drastically, since a single logical update must be performed on every copy of the database to keep the copies consistent.