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 |