TRANSACTION

& UNIT 5

CONCURRENCY CONTROL GD-UU_CSE/CA 1

TRANSACTION CONCEPTS:
A transaction is a collection of logically related operations
which reads and possibly updates the various data items in the
database. Usually, a transaction is initiated by a user program
written in high-level DML language (SQL), or programming
language, with an embedded database, accesses in JDBC or
ODBC.
In other words, we can say that any logical calculation which is
done in a consistent mode in the database is called a
transaction. Every database before and after the transaction
must be in a consistent state.
GD-UU_CSE/CA 2
 TRANSACTION CONCEPTS:
A transaction has the following properties to ensure the integrity
of data:
1. Atomicity
2. Consistency
3. Isolation
4. Durability

GD-UU_CSE/CA 3
SIMPLE TRANSACTION EXAMPLE
Suppose a bank employee transfers money from X’s account to
Y’s account. As the amount of 100Rs gets transferred from the X
account to Y’s account, the following series of operations are
performed in the background of the screen.

Simply we can say, the transaction involves many following

operations such as:

GD-UU_CSE/CA 4
 SIMPLE TRANSACTION EXAMPLE
1. Open the account of X
2. Read the old balance
3. Deduct the certain amount 100Rs from X account
4. saving new balance to X account
5. Open the account of Y
6. Read the old balance
7. Add the certain amount 100Rs to Y’s account
8. Save new balance to Y account
GD-UU_CSE/CA 5
 SIMPLE TRANSACTION EXAMPLE
X’s Account
Open_Account(X)
Old_Balance = X.balance
New_Balance = Old_Balance - 100
X.balance = New_Balance
Close_Account(X)
Y’s Account
Open_Account(Y)
Old_Balance = Y.balance
New_Balance = Old_Balance + 100
Y.balance = New_Balance
Close_Account(Y)

GD-UU_CSE/CA 6
 OPERATIONS OF TRANSACTION
Following are the two main operations in a transaction:
1. Read operation
2. Write operation
Read Operation: This operation transfers the data item from the
database and then stores it in a buffer in main memory.
Write Operation: This operation writes the updated data value
back to the database from the buffer.

GD-UU_CSE/CA 7
 OPERATIONS OF TRANSACTION
For example: Let Ti be a transaction that transfer Rs50 from X
account to Y account. This transaction can be defined as:
T i: read(X); ……. (1)
X := X-50; ……. (2)
write(X); ……. (3)
read(Y); ……. (4)
Y := Y + 50; ……. (5)
write(Y).……. (6)
Assume that the value of both X and Y before starting of the
transaction Ti is 100.
GD-UU_CSE/CA 8
OPERATIONS OF TRANSACTION
The first operation read the value of X(100) from the database and
stores it in a buffer.
The second operation will decrease X value by 50. So buffer will
contain 50.
The third operation will write the value of the buffer to the
database. So the final value of X will be 50.
The fourth operation read the value of Y(100) from the database
and stores it in a buffer.
The fifth operation will add X value by 50. So buffer will contain
150.
The sixth operation will write the value of buffer to the database.
So the final value of Y will be 150. GD-UU_CSE/CA 9
 OPERATIONS OF TRANSACTION
But, it may be possible that due to hardware or software failure
that transaction may fail before completing all the operations in the
set.
For example: If in the above transaction, the transaction fails after
executing operation 5, then Y's value will remain 100 in the
database, which is not acceptable by the bank.
To overcome this problem, we have two important operations
Commit and Rollback.
Commit Operation: This operation is used to save the work done
permanently in the database.
Rollback Operation: This operation is used to undo the work done.
GD-UU_CSE/CA 10
 TRANSACTION STATES:
A transaction passes through many different states in its life
cycle. These states are known as transaction states.
A transaction can be in one of the following states in the
database:
1. Active state
2. Partially committed state
3. Committed state
4. Failed state
5. Terminated state
GD-UU_CSE/CA 11
TRANSACTION STATES:

GD-UU_CSE/CA 12
TRANSACTION STATES:
Active State
➢This is the first state in every transaction life cycle.
➢A transaction is said to be in an active state when it starts
execution and performs read and write operations.
➢In this state, the transaction is being executed.
➢This is the initial state of every transaction.

GD-UU_CSE/CA 13
TRANSACTION STATES:
Partially committed state
➢This state is also an execution phase.
➢When a transaction executes its final operation, it is said to
be in a partially committed state.
➢Any transaction enters into this state when the final operation
of the transaction gets executed, but the data is still not saved
to the database.
GD-UU_CSE/CA 14
TRANSACTION STATES:
Committed state
➢Any transaction enters in committed state when all the operations
of transaction are completed successfully. And all the changes
made by the transaction are permanently saved into the database.

➢If a transaction executes all its operations successfully, it is said to

be committed. All its effects are now permanently established on
the database system.
GD-UU_CSE/CA 15
TRANSACTION STATES:
Failed state
➢Any transaction is entered in this state when the normal execution
of it can no longer proceed. Or we can say that, if any transaction
cannot proceed to the execution phase due to system failure, then
the transaction is said to be in a failed state.
➢A transaction is said to be in a failed state if any of the checks
made by the database recovery system fails. A failed transaction
can no longer proceed further.
GD-UU_CSE/CA 16
TRANSACTION STATES:
Aborted state
➢Any transaction is said to be in an aborted state when a transaction fails
in its execution and goes into a failed state. And all the changes made by
the transaction has to be rolled back to the previous consistent state.
➢The database recovery module can select one of the two operations
after a transaction aborts −
1. Re-start the transaction
2. Kill the transaction
GD-UU_CSE/CA 17
 TRANSACTION STATES:
Terminated State
➢Any transaction reaches terminated state when a specific
transaction which is leaving the system can't be restarted. After
the transaction is committed successfully or rollback due to
system or database failure, finally it indicates the transaction is
over.

GD-UU_CSE/CA 18
TRANSACTION STATES:
Example:
Transaction T
Let’s suppose a transaction T through BEGIN TRANSACTION
which you want to transfer 100Rs Read(X); ……………(1)
from account ‘X’ (source account) to X=X-50; ……………(2)
account ‘Y’ (destination account). Write(X); …………....(3)
Assume that the account balance of Read(Y); …………….(4)
X is 500 and Y is 1000. This Y=Y+50; ……………(5)
transaction T can be represented as: Write(Y); …………...(6)
Commit; …………...(7)
END TRANSACTION

GD-UU_CSE/CA 19
TRANSACTION STATES:
Example:
Transaction T
ACTIVE: When the above BEGIN TRANSACTION
transaction T starts, i.e., enters Read(X); ……………(1)
BEGIN TRANSACTION, the X=X-50; ……………(2)
transaction in an active state.
Write(X); …………....(3)
From BEGIN TRANSACTION and
Read(Y); …………….(4)
COMMIT statement, the
Y=Y+50; ……………(5)
transaction is in the ACTIVE state
Write(Y); …………...(6)
only.
Commit; …………...(7)
In an ACTIVE state, value of X= END TRANSACTION
500 and value of Y = 1000.
GD-UU_CSE/CA 20
TRANSACTION STATES:
Example:
PARTIALLY COMMITTED: If T
transaction reaches the
statement COMMIT, it goes into
partially committed state.
In PARTIALLY COMMITTED state,
X= 400 and Y= 1100;
Transaction T
BEGIN TRANSACTION
Read(X); ……………(1)
X=X-50; ……………(2)
Write(X); …………....(3)
Read(Y); …………….(4)
Y=Y+50; ……………(5)
Write(Y); …………...(6)
Commit; …………...(7)
END TRANSACTION
GD-UU_CSE/CA 21
 TRANSACTION
Example:
STATES:
FAILED: This state happens if one of the following
occurs: Transaction T
▪If any system or database failure happens to the BEGIN TRANSACTION
transaction in an ACTIVE state, then the transaction goes Read(X); ……………(1)
into an FAILED state.
X=X-50; ……………(2)
▪If the transaction failed before Write(X), then X = 500 Write(X); …………....(3)
and Y = 1000.
Read(Y); …………….(4)
▪If the transaction failed after Write(X), then X= 400
and Y = 1000. Y=Y+50; ……………(5)
▪If the transaction failed before Commit and after Write(Y); …………...(6)
WRITE(Y)statement, then X = 400 and Y = 1100. Commit; …………...(7)
If any failure happen to the above transaction T in a END TRANSACTION
partially committed state, then the transaction goes into
the failed state, the value of X is 500, and Y is 1000. GD-UU_CSE/CA 22
 TRANSACTION STATES:
ABORTED: In an aborted state, X= 500
and Y= 1000. [X and Y both are rolled Transaction T
back to Old consistent state] BEGIN TRANSACTION
Read(X); ……………(1)
COMMITTED: If above transaction T X=X-50; ……………(2)
executes COMMIT statement Write(X); …………....(3)
successfully. In other words, if it Read(Y); …………….(4)
successfully writes the new value of X Y=Y+50; ……………(5)
and Y into the database or a log file, Write(Y); …………...(6)
then the transaction is said to be in a Commit; …………...(7)
committed state. END TRANSACTION
In COMMITTED state, X = 400 and Y =
1100. [New consistent state] GD-UU_CSE/CA 23
 TRANSACTION PROPERTIES
A transaction in a database has the following four properties,
known as ACID properties. These properties are used to
maintain the consistency of the database in the case of system
failure and concurrent access.
A transaction in a database system must maintain Atomicity,
Consistency, Isolation, and Durability − commonly known as
ACID properties − in order to ensure accuracy, completeness,
and data integrity.

GD-UU_CSE/CA 24
 TRANSACTION PROPERTIES
1. Atomicity
2. Consistency
3. Isolation
4. Durability

GD-UU_CSE/CA 25
 TRANSACTION PROPERTIES
1. Atomicity:
This property ensures that no transaction in the database occurs
partially completed. This property also referred to as all or
nothing rule i.e. all operations of a transaction is either fully
completed or not execute at all.
Atomicity property involves abort and commit operations.
Abort: If a transaction in a database aborts, then all the
changes made are not visible to the user.
Commit: If a transaction in a database commits, then all the
changes made are visible to the user. GD-UU_CSE/CA 26
 TRANSACTION PROPERTIES
1. Atomicity:
This property states that a transaction must be treated as an
atomic unit, that is, either all of its operations are executed or
none.
There must be no state in a database where a transaction is left
partially completed.
States should be defined either before the execution of the
transaction or after the execution/abortion/failure of the
transaction.
GD-UU_CSE/CA 27
 TRANSACTION PROPERTIES
1. Atomicity: Example Transaction T
Read(X) …..(1)
Let’s suppose a transaction T through
X=X-50; ……(2)
which you want to transfer money from
Write(X) …..(3)
account ‘X’ (source account) to account ‘Y’
(destination account). Assume that the Read(Y) …..(4)
account balance of X is 100 and Y is 400. Y=Y+50 …..(5)
This transaction T can be represented as: Write(Y) …..(6)
Commit; …..(7)

GD-UU_CSE/CA 28
 TRANSACTION PROPERTIES
1. Atomicity: Example
In this transaction T, the steps 1 – 7 must be Transaction T
completed to ensure the atomicity property. Read(X) …..(1)
If any failure happens before reaching X=X-50; ……(2)
COMMIT operation, then we must see old Write(X) …..(3)
consistent values of X=100 and Y=400 using Read(Y) …..(4)
the rollback command. Y=Y+50 …..(5)
If no failure occurs, then we must see the new Write(Y) …..(6)
consistent values of X=50 and Y=450. Commit; …..(7)
GD-UU_CSE/CA 29
 TRANSACTION PROPERTIES
2. Consistency:
This property states that every database must remain in a
consistent state after the transaction.
If any transaction violates the consistency rules of the database,
the whole transaction will be rolled back, and the database will
be restored to a consistent state with those rules.
No transaction should have any adverse effect on the data
residing in the database.
It is the responsibility of the application programmer and DBMS
to maintain the consistency of the database GD-UU_CSE/CA 30
 TRANSACTION PROPERTIES
2. Consistency: Example Transaction T
Read(X) …..(1)
Let’s suppose a transaction T through X=X-50; ……(2)
which you want to transfer money from Write(X) …..(3)
account ‘X’ (source account) to account
Read(Y) …..(4)
‘Y’ (destination account). Assume that
the account balance of X is 100 and Y Y=Y+50 …..(5)
is 400. This transaction T can be Write(Y) …..(6)
represented as: Commit; …..(7)

GD-UU_CSE/CA 31
 TRANSACTION PROPERTIES
2. Consistency: Example
Transaction T
In this transaction, the old values of X and Read(X) …..(1)
Y are 100 and 400 respectively X=X-50; ……(2)
i.e.,(X+Y=500 before the transaction). The Write(X) …..(3)
operations or calculations that change X Read(Y) …..(4)
and Y values are X = X-50 and Y= Y+50. If Y=Y+50 …..(5)
the steps (1-7) in a transaction are Write(Y) …..(6)
executed successfully. Commit; …..(7)

GD-UU_CSE/CA 32
 TRANSACTION PROPERTIES
2. Consistency: Example
Transaction T
And there is no other transaction which Read(X) …..(1)
change values of X or Y during execution of X=X-50; ……(2)
T, then the new values of X and Y will be 50 Write(X) …..(3)
and 450 i.e., (X+Y=500 after the Read(Y) …..(4)
transaction). So, the value of X+Y is 500
Y=Y+50 …..(5)
before and after the transaction. This
shows the transaction is in the consistent Write(Y) …..(6)
state. Commit; …..(7)

GD-UU_CSE/CA 33
 TRANSACTION PROPERTIES
3. Isolation:
Isolation property is needed when there are concurrent
transactions in a database.
This property states that a data of transaction T1 which is in
execution, then transaction T2 cannot access the result of
transaction T1 until the operations of a transaction T1 is
completed. Or, we can say that a user cannot perform the same
operation in multiple transactions at the same time. The
execution of all transaction should be isolated from other
transaction.
GD-UU_CSE/CA 34
 TRANSACTION PROPERTIES
3. Isolation:
In a database system where more than one transaction are
being executed simultaneously and in parallel, the property of
isolation states that all the transactions will be carried out and
executed as if it is the only transaction in the system.
No transaction will affect the existence of any other transaction.

GD-UU_CSE/CA 35
 TRANSACTION PROPERTIES
3. Isolation: Example
Transaction T
Let’s suppose a transaction T through which Read(X) …..(1)
you want to transfer money from account ‘X’ X=X-50; ……(2)
(source account) to account ‘Y’ (destination Write(X) …..(3)
account). Assume that the account balance of Read(Y) …..(4)
X is 100 and Y is 400. This transaction T can Y=Y+50 …..(5)
be represented as: Write(Y) …..(6)
Commit; …..(7)

GD-UU_CSE/CA 36
 TRANSACTION PROPERTIES
3. Isolation: Example
• In above transaction T, first, we change X Transaction T
from 100 to 50. Then we change Y from 400 to Read(X) …..(1)
X=X-50; ……(2)
450. During T transaction, we should not allow Write(X) …..(3)
other transactions to see or to use the old and Read(Y) …..(4)
the new values of X or Y before commit the Y=Y+50 …..(5)
statement, i.e., step 7. The transaction T Write(Y) …..(6)
Commit; …..(7)
should not be interfered by other transactions
during its execution process. GD-UU_CSE/CA 37
 TRANSACTION PROPERTIES
4. Durability:
This property states that, when all the operations of a
transaction are completed successfully, then the changes made
by the transaction saved to the database should be permanent.
These changes are never lost if there occurs any kind of failure.
The database should be durable enough to hold all its latest
updates even if the system fails or restarts.

GD-UU_CSE/CA 38
 TRANSACTION PROPERTIES
4. Durability:
If a transaction updates data in a DB and commits, then the DB
will hold the modified data.
If a transaction commits but the system fails before the data
could be written on to the disk, then that data will be updated
once the system springs back into action.

GD-UU_CSE/CA 39
 TRANSACTION PROPERTIES
4. Durability: Example Transaction T
Read(X) …..(1)
Let’s suppose a transaction T through which you want to X=X-50; ……(2)
transfer money from account ‘X’ (source account) to Write(X) …..(3)
account ‘Y’ (destination account). Assume that the Read(Y) …..(4)
Y=Y+50 …..(5)
account balance of X is 100 and Y is 400. This Write(Y) …..(6)
transaction T can be represented as: Commit; …..(7)
• In above transaction T, we must see 50 and 450 as the current
balances of account X and Y respectively after the commit statement
has reached. If any failure occurs, we must not lose the updates after
the commit statement.
GD-UU_CSE/CA 40
 SCHEDULE
• When several transactions are executing concurrently then
the order of various instructions is known as a schedule.
That is it indicates the chronological order in which
instructions of concurrent transactions are executed.
• A schedule for a set of transactions must consist of all
instructions of those transactions and it must preserve the
order in which the instructions appear in each individual
transaction.
GD-UU_CSE/CA 41
 SCHEDULE
• A schedule that contains either an abort or a commit for
each transaction whose actions are listed in it is called a
'complete schedule'.
• If the actions of different transactions are not interleaved
that is transaction are executed from start to finish one by
one. We call the schedule is 'serial schedule’.
• A schedule can have many transactions in it, each
comprising of a number of instructions/tasks.
GD-UU_CSE/CA 42
 SERIAL SCHEDULE
• It is a schedule in which transactions are aligned in such a
way that one transaction is executed first.
• When the first transaction completes its cycle, then the next
transaction is executed.
• Transactions are ordered one after the other. This type of
schedule is called a serial schedule, as transactions are
executed in a serial manner.

GD-UU_CSE/CA 43
 SERIAL SCHEDULE
• In a multi-transaction environment, the execution sequence
of an instruction in a transaction cannot be changed, but
two transactions can have their instructions executed in a
random fashion.
• This execution does no harm if two transactions are
mutually independent and working on different segments of
data.

GD-UU_CSE/CA 44
 SERIAL SCHEDULE
• But in case these two transactions are working on the same
data, then the results may vary. This ever-varying result may
bring the database to an inconsistent state.
• To resolve this problem, we allow parallel execution of a
transaction schedule, if its transactions are either
serializable or have some equivalence relation among them.

GD-UU_CSE/CA 45
 SERIAL SCHEDULE
Transaction 1 Transaction 2
R(x)
W(x)
R(y)
Example of Serial Schedule
W(y)
R(y)
W(y)
R(x)
W(x) GD-UU_CSE/CA 46
 NON-SERIAL SCHEDULE
• The Non-Serial schedule is a type of schedule where
transactions are executed concurrently, with some overlap
in time. Unlike a serial schedule, where transactions are
executed one after the other with no overlap, a non-serial
schedule allows transactions to execute simultaneously

GD-UU_CSE/CA 47
 NON-SERIAL SCHEDULE
Transaction 1 Transaction 2
R(x)
W(x)
R(y)
Example of Non-Serial
Schedule W(y)
R(y)
R(x)
W(y)
W(x) GD-UU_CSE/CA 48
 DIFFERENCE BETWEEN SERIAL SCHEDULE
AND NON-SERIAL SCHEDULE
Serial Schedule Non-serial schedule
• A Serial schedule is a • A non- serial schedule is a
sequence of operation by schedule where the
a set of concurrent operations of a group of
transaction that preserves concurrent transactions are
the order of operations in interleaved .
each of the individual
transaction
GD-UU_CSE/CA 49
 DIFFERENCE BETWEEN SERIAL SCHEDULE
AND NON-SERIAL SCHEDULE
Serial Schedule Non-serial schedule
• Transaction are performed • Transaction are performed in
in serial order. non-serial order, but the result
be same as serial.
• No interference between • Concurrency problem can
transactions arise here.

GD-UU_CSE/CA 50
 DIFFERENCE BETWEEN SERIAL SCHEDULE
AND NON-SERIAL SCHEDULE
Serial Schedule Non-serial schedule
• It does not matter which • The problem e have seen earlier
transaction is executed first, as lost update, uncommitted data,
long as every transaction is inconsistent analysis is arise if
executed in it’s entirely from the scheduling is not proper.
beginning to end.

GD-UU_CSE/CA 51
 DIFFERENCE BETWEEN SERIAL SCHEDULE
AND NON-SERIAL SCHEDULE
Serial Schedule
A serial schedule gives the
benefits of concurrent execution
without any problem.
If we consider transaction to be
independent serial schedule is
correct based on (property
ACID) above assumption is
valid.
Non-serial schedule
In this schedule there is no any
benefit of concurrent execution.
The objective behind serializability
is to find the non-serial schedule
that allows transactions to execute
concurrently without interfering
one another. GD-UU_CSE/CA 52
 DIFFERENCE BETWEEN SERIAL SCHEDULE
AND NON-SERIAL SCHEDULE
Serial Schedule Non-serial schedule
Example: If some transaction T Example: In this schedule the
is long ,the other transaction execution of other transaction
must wait for T to complete all goes on without waiting the
its operations. completion of T.

GD-UU_CSE/CA 53
 DIFFERENCE BETWEEN SERIAL SCHEDULE
AND SERIALIZABLE SCHEDULE:
S.NO. Serial Schedule Serializable Schedule
In Serial schedule, transactions will be In Serializable schedule transaction are
1
executed one after other. executed concurrently.

2 Serial schedule are less efficient. Serializable schedule are more efficient.

In serial schedule only one transaction In Serializable schedule multiple

3
executed at a time. transactions can be executed at a time.

Serial schedule takes more time for

4 In Serializable schedule execution is fast.
execution.
GD-UU_CSE/CA 54
 SERIALIZABILITY
• Serializability is the concept in a transaction that helps to
identify which non-serial schedule is correct and will maintain
the database consistency. It relates to the isolation property
of transaction in the database.
• Serializability is the concurrency scheme where the
execution of concurrent transactions is equivalent to the
transactions which execute serially.

GD-UU_CSE/CA 55
 SERIALIZABILITY
Serializable Schedule
• A serial schedule is always a serializable schedule because any
transaction only starts its execution when another transaction has
already completed its execution. However, a non-serial schedule
of transactions needs to be checked for Serializability.
• Note: If a schedule of concurrent ‘n' transactions can be
converted into an equivalent serial schedule. Then we can say
that the schedule is serializable. And this property is known as
serializability. GD-UU_CSE/CA 56
TESTING OF SERIALIZABILITY
Testing for serializability in a database management
system (DBMS) is an important step in ensuring that
concurrent transactions executing in the database do
not produce inconsistent or incorrect results.
Serializability testing involves verifying that a given
schedule of transactions is serializable, meaning that
the effects of running the transactions concurrently are
equivalent to running them serially, one after the other.
GD-UU_CSE/CA 57
TESTING OF SERIALIZABILITY
We can use below two techniques to test serializability
in DBMS:

1. Serialization Graph
2. Precedence Graph

GD-UU_CSE/CA 58
 TESTING OF SERIALIZABILITY
It can be described as a Graph G(V, E) with vertices V =
"V1, V2, V3,…, Vn" and directed edges E = "E1, E2, E3,…,
En".
One of the two operations—READ or WRITE—performed by
a certain transaction is contained in the collection of edges.

The meaning of the above graph is that, before Transaction y ,

Transaction x is performing a read or write operation. GD-UU_CSE/CA 59
TYPES OF SERIALIZABILITY
There are mainly two types of serializability in DBMS:

1. View Serializability
2. Conflict Serializability

GD-UU_CSE/CA 60
TYPES OF SERIALIZABILITY
1. View Serializability:
View Serializability is the process of determining whether or
not a given schedule is view serializable. If a schedule is a
view equivalent to a serial schedule, it is view serializable.
To test for view serializability, we first identify the read and
write operations of each transaction.
A schedule is considered view serializable if it is view
equivalent to a serial schedule, which is a schedule where the
transactions are executed one after the other without any
overlap.
GD-UU_CSE/CA 61
 TYPES OF SERIALIZABILITY 1. View Serializability:
Transaction 1 Transaction 2
Transaction 1 Transaction 2
Let’s swap the R(a)
R(a)
read-write
W(a)
W(a) operations in
R(a)
the middle of R(b)
the two W(b)
W(a) transactions to
create the view R(a)
R(b)
equivalent W(a)
W(b) schedule.
R(b)
R(b)
W(b)
W(b)
GD-UU_CSE/CA 62
TYPES OF SERIALIZABILITY
2. Conflict Serializability :
A database management system (DBMS) schedule’s
ability to prevent the sequence of conflicting
transactions from having an impact on the transactions’
results is known as conflict serializability in DBMS.
Conflicting transactions are those that make
unauthorized changes to the same database data item.

GD-UU_CSE/CA 63
TYPES OF SERIALIZABILITY
2. Conflict Serializability :Conflict serializability is a type of
conflict operation in serializability that operates the same
data item that should be executed in a particular order and
maintains the consistency of the database.
In DBMS, each transaction has some unique value, and every
transaction of the database is based on that unique value of
the database.
This unique value ensures that no two operations having the
same conflict value are executed concurrently.
GD-UU_CSE/CA 64
TYPES OF SERIALIZABILITY
2. Conflict Serializability :
For example, let's consider two examples, i.e., the order table and
the customer table. One customer can have multiple orders, but
each order only belongs to one customer. There is some condition
for the conflict serializability of the database.
These are as below.
• Both operations should have different transactions.
• Both transactions should have the same data item.
• There should be at least one write operation between the two
operations GD-UU_CSE/CA 65
TYPES OF SERIALIZABILITY
2. Conflict Serializability :
If there are two transactions that are executed concurrently,
one operation has to add the transaction of the first customer,
and another operation has added by the second operation.
This process ensures that there would be no inconsistency in the
database.

GD-UU_CSE/CA 66
 TYPES OF SERIALIZABILITY 2. Conflict Serializability:
Transaction 1 Transaction 2 Transaction 3
Let’s see how a precedence
R(x) graph looks like of above
R(y) schedule.
R(x)

R(y)

R(z)

W(y)

W(z)

R(z)

W(x)

W(z) GD-UU_CSE/CA 67
 TYPES OF SERIALIZABILITY 2. Conflict Serializability:

Let’s see how a precedence graph looks like of above schedule.

In the above precedence graph, we can see that there is

no cycle present in the graph. So, we can say that the
above schedule is conflict serializable. GD-UU_CSE/CA 68
 BENEFITS OF SERIALIZABILITY IN DBMS
Predictable execution: In serializable, all the threads of the
DBMS are executed at one time. There are no such surprises
in the DBMS. In DBMS, all the variables are updated as
expected, and there is no data loss or corruption.
Easier to Reason about & Debug: In DBMS all the threads are
executed alone, so it is very easier to know about each
thread of the database. This can make the debugging
process very easy. So we don't have to worry about the
concurrent process.
GD-UU_CSE/CA 69
 BENEFITS OF SERIALIZABILITY IN DBMS
Reduced Costs: With the help of serializable property, we
can reduce the cost of the hardware that is being used for
the smooth operation of the database. It can also reduce the
development cost of the software.
Increased Performance:In some cases, serializable
executions can perform better than their non-serializable
counterparts since they allow the developer to optimize their
code for performance

GD-UU_CSE/CA 70
 NEED OF CONCURRENCY CONTROL
Concurrency control is a method of managing multiple transactions or
operations that are running simultaneously.
It occurs in the multiuser system, where more than one user executes
some transaction at the same time.
Executing any transaction simultaneously will lead to inefficient system
performance, very high waiting time and response time, and decrease
resource utilization without concurrency control.
The transaction processes are made in a very large database, and
thousands of concurrent users are executing the database transaction
at the same time.
GD-UU_CSE/CA 71
 NEED OF CONCURRENCY CONTROL
Let us suppose 1000 users are trying to perform some
online banking or ATM transaction. So without
concurrency, all the transaction takes too much time to
process, or it may also be possible that they won’t be
able to perform the transaction, and the integrity is not
maintained without concurrency.
In this situation, the transactions are also conflicting
and not maintaining any consistency will also lead to
failure to processed transactions. GD-UU_CSE/CA 72
 NEED OF CONCURRENCY CONTROL
The concurrency control method ensures the
transactions to, be concurrent, accurate, and give
correct results without violating data integrity.
It preserves database consistency and provides data
isolation between conflicting transactions.
It also ensures serializability. It also reduces the
waiting time and response time of the system and
enhances resource utilization which further enhances
the efficiency and system performance. GD-UU_CSE/CA 73
 ADVANTAGES OF CONCURRENCY:
In general, concurrency means, that more than one transaction
can work on a system.
The advantages of a concurrent system are:
• Waiting Time: It means if a process is in a ready state but
still the process does not get the system to get execute is
called waiting time. So, concurrency leads to less waiting time.
• Response Time: The time wasted in getting the response
from the CPU for the first time, is called response time. So,
concurrency leads to less Response Time.
GD-UU_CSE/CA 74
 ADVANTAGES OF CONCURRENCY:
• Resource Utilization: The amount of Resource utilization in a
particular system is called Resource Utilization. Multiple
transactions can run parallel in a system. So, concurrency
leads to more Resource Utilization.
• Efficiency: The amount of output produced in comparison to
given input is called efficiency. So, Concurrency leads to more
Efficiency.

GD-UU_CSE/CA 75
 DISADVANTAGES OF CONCURRENCY:
Overhead: Implementing concurrency control requires additional
overhead, such as acquiring and releasing locks on database
objects. This overhead can lead to slower performance and
increased resource consumption, particularly in systems with high
levels of concurrency.
Deadlocks: Deadlocks can occur when two or more transactions
are waiting for each other to release resources, causing a circular
dependency that can prevent any of the transactions from
completing. Deadlocks can be difficult to detect and resolve, and
can result in reduced throughput and increased latency.
GD-UU_CSE/CA 76
 DISADVANTAGES OF CONCURRENCY:
Reduced concurrency: Concurrency control can limit the number
of users or applications that can access the database
simultaneously. This can lead to reduced concurrency and slower
performance in systems with high levels of concurrency.
Complexity: Implementing concurrency control can be complex,
particularly in distributed systems or in systems with complex
transactional logic. This complexity can lead to increased
development and maintenance costs.

GD-UU_CSE/CA 77
 DISADVANTAGES OF CONCURRENCY:
Inconsistency: In some cases, concurrency control can lead to
inconsistencies in the database. For example, a transaction that is
rolled back may leave the database in an inconsistent state, or a
long-running transaction may cause other transactions to wait for
extended periods, leading to data staleness and reduced
accuracy.

GD-UU_CSE/CA 78
NEED OF RECOVERY
Recovery is an essential feature in Database Management
Systems (DBMS) because it ensures that data can be
restored to a consistent and correct state in case of
failures or errors.
The DBMS can experience various types of failures, such
as hardware failures, software bugs, or power outages,
which can lead to data corruption or loss.
Recovery mechanisms can help restore the database to a
consistent state after such failures.
GD-UU_CSE/CA 79
 NEED OF RECOVERY
There are basically the following types of failures that may
occur and leads to the failure of the transaction such as:
Transaction failure, System failure, Media failure and so on.
System crash – A hardware, software, or network error
occurs comes under this category this type of failure
basically occurs during the execution of the transaction.
Hardware failures are basically considered Hardware
failures.
GD-UU_CSE/CA 80
 NEED OF RECOVERY
System error – Some operation that is performed during
the transaction is the reason for this type of error to occur,
such as integer or divide by zero.
This type of failure is also known as the transaction which
may also occur because of erroneous parameter values or
because of a logical programming error.
In addition to this user may also interrupt the execution
during execution which may lead to failure in the transaction
GD-UU_CSE/CA 81
 FAILURE
Failure in terms of a database can be defined as its
inability to execute the specified transaction or loss of data
from the database.
A DBMS is vulnerable to several kinds of failures and each
of these failures needs to be managed differently.
There are many reasons that can cause database failures
such as network failure, system crash, natural disasters,
carelessness, sabotage(corrupting the data intentionally),
software errors, etc.
GD-UU_CSE/CA 82
 CLASSIFICATION OF FAILURE
To see wherever the matter has occurred, we tend to
generalize a failure into numerous classes, as follows:
❑Transaction failure
❑System crash
❑Disk failure

GD-UU_CSE/CA 83
CLASSIFICATION OF FAILURE

GD-UU_CSE/CA 84
 CLASSIFICATION OF FAILURE
Transaction failure: A transaction needs to stop if it cannot
run or if it gets stuck. This is called transaction failure and it
affects some transactions or processes.
This is often known as transaction failure wherever solely
many transactions or processes are hurt.
The reasons for transaction failure are:
1. Logical errors
2. System errors
GD-UU_CSE/CA 85
 CLASSIFICATION OF FAILURE
Logical errors: When a transaction fails to finish
because of a mistake in its code or a problem inside
itself.
System errors: When the data system itself stops an
active transaction because the DBMS cannot run it, or it
has to quit because of some system condition. For
example, if there is a problem or a lack of resources,
the system stops an active transaction.
GD-UU_CSE/CA 86
 CLASSIFICATION OF FAILURE
System crash: System crash: There are problems -
outside the system - that can make the system stop
suddenly and cause the system to crash. For example,
power cuts might cause the failure of hardware or
software below the system. Examples could include OS
errors.

GD-UU_CSE/CA 87
 CLASSIFICATION OF FAILURE
Disk failure: In the early days of technology
development, it was a common problem where hard-
disk drives or storage drives used to fail often. Disk
failures include the creation of bad sectors, inability to
access the disk, disk crash or any other failure that
destroys all or part of disk storage.

GD-UU_CSE/CA 88
LOCK BASED PROTOCOL
In this type of protocol, any transaction cannot read or
write data until it acquires an appropriate lock on it.
There are two types of lock:
1. Shared lock (LOCK-S)
2. Exclusive lock (LOCK-X)

GD-UU_CSE/CA 89
LOCK BASED PROTOCOL
1. Shared lock:
• It is also known as a Read-only lock.
• In a shared lock, the data item can only read by the
transaction.
• It can be shared between the transactions because when
the transaction holds a lock, then it can't update the data
on the data item.
•Denoted By- LOCK(S) GD-UU_CSE/CA 90
LOCK BASED PROTOCOL
1. Shared 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.

GD-UU_CSE/CA 91
LOCK BASED PROTOCOL
1. Shared lock:
• 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.

GD-UU_CSE/CA 92
LOCK BASED PROTOCOL
2. Exclusive lock:
•In the exclusive lock, the data item can be both reads as
well as written by the transaction.
•This lock is exclusive, and in this lock, multiple transactions
do not modify the same data simultaneously.
•Denoted By- LOCK(X)

GD-UU_CSE/CA 93
LOCK BASED PROTOCOL
2. Exclusive lock:
•With the Exclusive Lock, a data item can be read as well
as written. This is exclusive and can't be held concurrently
on the same data item. X-lock is requested using lock-x
instruction. Transactions may unlock the data item after
finishing the 'write' operation.

GD-UU_CSE/CA 94
LOCK BASED PROTOCOL
2. Exclusive lock:
•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.

GD-UU_CSE/CA 95
LOCK BASED PROTOCOL
There are four types of lock protocols available:
1. Simplistic lock protocol
2. Pre-claiming Lock Protocol
3. Two-phase locking (2PL)
4. Strict Two-phase locking (Strict-2PL)

GD-UU_CSE/CA 96
LOCK BASED PROTOCOL
1. Simplistic lock protocol
This type of lock-based protocols allows transactions to
obtain a lock on every object before beginning operation.
Transactions may unlock the data item after finishing the
'write' operation.

GD-UU_CSE/CA 97
LOCK BASED PROTOCOL
2. Pre-claiming Lock Protocol
Pre-claiming lock protocol helps to evaluate operations
and create a list of required data items which are needed
to initiate an execution process. In the situation when all
locks are granted, the transaction executes. After that, all
locks release when all of its operations are over.

GD-UU_CSE/CA 98
 TWO PHASE LOCKING PROTOCOL
The two-phase locking protocol divides the execution phase of
the transaction into three parts.
In the first part, when the execution of the transaction starts, it
seeks permission for the lock it requires.
In the second part, the transaction acquires all the locks. The
third phase is started as soon as the transaction releases its first
lock.
In the third part, the transaction cannot demand any new locks.
It only releases the acquired locks.
GD-UU_CSE/CA 99
 TWO PHASE LOCKING PROTOCOL

There are two phases of 2PL:

Growing phase: In the growing phase, a new lock on the data item may
be acquired by the transaction, but none can be released.
Shrinking phase: In the shrinking phase, existing lock held by the
transaction may be released, but no new locks can be acquired.
GD-UU_CSE/CA 100
TWO PHASE LOCKING PROTOCOL

GD-UU_CSE/CA 101
 TWO PHASE LOCKING PROTOCOL
In this example, if lock conversion is
allowed then the following phase
can happen:
1. Upgrading of lock (from S(a)
to X (a)) is allowed in growing
phase.
2. Downgrading of lock (from
X(a) to S(a)) must be done in
shrinking phase.
GD-UU_CSE/CA 102
 TWO PHASE LOCKING PROTOCOL
The following way shows how unlocking and locking
work with 2-PL.
Transaction T1:
Growing phase: from step 0-2
Shrinking phase: from step 4-7
Lock point: at 3
Transaction T2:
Growing phase: from step 1-5
Shrinking phase: from step 7-8
Lock point: at 6 GD-UU_CSE/CA 103
LOCK POINT
➢ In the growing phase transaction reaches a point where
all the locks it may need has been acquired. This point is
called LOCK POINT. After the lock point has been
reached, the transaction enters a shrinking phase
➢ The “Lock Point” is when all locks are held for the whole
transaction.
➢ After the lock point has been reached, the transaction
enters a shrinking phase.
GD-UU_CSE/CA 104
TWO PHASE LOCKING PROTOCOL

GD-UU_CSE/CA 105
TWO PHASE LOCKING
PROTOCOL

GD-UU_CSE/CA 106
TWO PHASE LOCKING
PROTOCOL

GD-UU_CSE/CA 107
TWO PHASE LOCKING
PROTOCOL

GD-UU_CSE/CA 108
ANY QUERY..?