BISQL – Laymen to SQL Developer # 37 – Concurrency Control Techniques #2 – The Two Phase Locking Protocol
Hi Folks,
This post is part of Series Database Management Systems
Currently running topic for this series is listed as below :
Series of Database Management Systems
>>Chapter 1 : DBMS [Database Management Systems]
>>Chapter 2 : Database Core Concepts and Applications
>>Chapter 3 : Record Storage and Primary File Organization
>>Chapter 4 : Index Structures of Files
>>Chapter 5 : Entity-Relationship Model
>>Chapter 6 : Relational Algebra
>>Chapter 7 : SQL
>>Chapter 8 : Functional Dependencies and Normalization For Relational Databases
>>Chapter 9 : Transaction Processing
>>Chapter 10 : Concurrency Control Techniques<You are Here>
Continuing from my previous post on this series.
We are going to Cover the Following Points in this article
- The Two Phase Locking Protocol
The Two Phase Locking Protocol
The two phase locking protocol is a process to access the shared resources as their own without creating deadlocks. This process consists of two phases.
1. Growing Phase: In this phase the transaction may acquire lock, but may not release any locks. Therefore this phase is also called as resource acquisition activity.
2. Shrinking phase: In this phase the transaction may release locks, but may not acquire any new locks. This includes the modification of data and release locks. Here two activities are grouped together to form second phase.
IN the beginning, transaction is in growing phase. Whenever lock is needed the transaction acquires it. As the lock is released, transaction enters the next phase and it can stop acquiring the new lock request.
Strict two phase locking:
In the two phases locking protocol cascading rollback are not avoided. In order to avoid this slight modification are made to two phase locking and called strict two phase locking. In this phase all the locks are acquired by the transaction are kept on hold until the transaction commits.
Deadlock & starvation: In deadlock state there exists, a set of transaction in which every transaction in the set is waiting for another transaction in the set.
Suppose there exists a set of transactions waiting
{T1, T2, T3,……………….., Tn) such that T1 is waiting for a data item existing in T2, T2 for T3 etc… and Tn is waiting of T1. In this state none of the transaction will progress.
Hope you will like Series of Database Management Systems series !
If you have not yet subscribe this Blog , Please subscribe it from “follow me” tab !
So that you will be updated @ real time and all updated knowledge in your mail daily for free without any RSS subscription OR news reading !!
Happy Learning and Sharing !!
For More information related to BI World visit our all Mentalist networks Blog
SQL Server Mentalist … SQL Learning Blog
Business Intelligence Mentalist … Business Intelligence World
Microsoft Mentalist … MVC,ASP.NET, WCF & LinQ
MSBI Mentalist … MS BI and SQL Server
NMUG Bloggers …Navi Mumbai User Group Blog
Architectural Shack … Architectural implementation and design patterns
DBA Mentalist …Advance SQL Server Blog
MVC Mentalist … MVC Learning Blog
Link Mentalist … Daily Best link @ your email
Infographics Mentalist … Image worth explaining thousand Words
Hadoop Mentalist … Blog on Big Data
BI Tools Analysis … BI Tools
Connect With me on
| Facebook |Twitter | LinkedIn| Google+ | Word Press | RSS | About Me |
SQL Server Mentalist 