0% found this document useful (0 votes)
11 views

Dbms Project

Uploaded by

ARJUNA.R
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
11 views

Dbms Project

Uploaded by

ARJUNA.R
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

FUNDAMENTALS OF DATABASE MANAGEMENT

SYSTEM

TOPIC:
ABOUT CONCURRENCY MANAGEMENT

ARJUNA.R
AND
GIRIJAMBA.M
BCOM(BDA)

1|Page
INDEX
SL NO CONTENT PAGE NO
1 What is concurrency 3
management
2 What is Transaction 3-5
3 Properties of 5-6
Transaction
4 What is Schedule 6-7
5 Difference between 8
serial schedule and
serializable schedule
6 Concurrency Control 8-9
in DBMS
7 Concurrency Control 9-10
Problems
8 Concurrency Control 10-12
Protocol
9 Advantages of 12-13
Concurrency control
10 Disadvantages of 13
Concurrency Control
11 Conclusion of 14
Concurrency control
12 Bibliography 15

2|Page
WHAT IS CONCURRENCY MANAGEMENT
Concurrency management in a database management system
(FDBMS) is the process of controlling and managing the execution
of transactions that access the same data simultaneously. This is
necessary to maintain the integrity and consistency of the data,
as concurrent transactions can lead to issues such as dirty reads,
lost updates, and phantom reads.
Concurrency control is crucial in FDBMS to ensure that the
database remains consistent and reliable, even when multiple
transactions are being executed simultaneously.

What is Transaction?
A transaction is a collection of operations that performs a single
logical function in a database application. Each transaction is a
unit of both atomicity and consistency. Thus, we require that
transactions do not violate any database consistency constraints.
That is, if the database was consistent when a transaction started,
the database must be consistent when the transaction
successfully terminates. However, during the execution of a
transaction, it may be necessary temporarily to allow
inconsistency, since either the debit of A or the credit of B must be
done before the other. This temporary inconsistency, although
necessary, may lead to difficulty if a failure occurs.
It is the programmer’s responsibility to define properly the various
transactions, so that each preserves the consistency of the
database. For example, the transaction to transfer funds from the
account of department A to the account of department B could
be defined to be composed of two separate programs: one that
debits account A, and another that credits account B. The
execution of these two programs one after the other will indeed
preserve consistency. However, each program by itself does not
transform the database from a consistent state to a new
consistent state. Thus, those programs are not transactions.

3|Page
The concept of a transaction has been applied broadly in
database systems and applications. While the initial use of
transactions was in financial applications, the concept is now
used in real-time applications in telecommunication, as well as in
the management of long-duration activities such as product
design or administrative workflows.
A set of logically related operations is known as a transaction.
The main operations of a transaction are:
Read(A): Read operations Read(A) or R(A) reads the value of A
from the database and stores it in a buffer in the main memory.
Write (A): Write operation Write(A) or W(A) writes the value back
to the database from the buffer.
(Note: It doesn’t always need to write it to a database back it just
writes the changes to buffer this is the reason where dirty read
comes into the picture)
Let us take a debit transaction from an account that consists of
the following operations:
R(A);
A=A-1000;
W(A);
Assume A’s value before starting the transaction is 5000.
The first operation reads the value of A from the database and
stores it in a buffer.
the Second operation will decrease its value by 1000. So buffer will
contain 4000.
the Third operation will write the value from the buffer to the
database. So A’s final value will be 4000.
But it may also be possible that the transaction may fail after
executing some of its operations. The failure can be because
of hardware, software or power, etc. For example, if the debit
transaction discussed above fails after executing operation 2, the
value of A will remain 5000 in the database which is not

4|Page
acceptable by the bank. To avoid this, Database has two
important operations:
Commit: After all instructions of a transaction are successfully
executed, the changes made by a transaction are made
permanent in the database.
Rollback: If a transaction is not able to execute all operations
successfully, all the changes made by a transaction are undone.

PROPERTIES OF TRANSACTION
In a relational database management system (RDBMS), a
transaction is a logical unit of work that performs a set of
operations on the database. The properties of a transaction in an
RDBMS are defined by the ACID (Atomicity, Consistency, Isolation,
and Durability) properties.
Atomicity: This property ensures that a transaction either
completes successfully or is rolled back completely. It prevents the
database from being left in an inconsistent state if a transaction
fails.
Consistency: This property ensures that the database remains in a
valid state before and after the transaction. It prevents the
database from being left in an inconsistent state due to the
transaction.
Isolation: This property ensures that the transaction is executed as
if it were the only transaction in the system. It prevents the
transaction from being affected by concurrent transactions,
ensuring that the transaction sees a consistent view of the
database.
Durability: This property ensures that the changes made by a
transaction are permanent and survive system failures. It ensures
that the database remains in a consistent state even after a
system failure.

5|Page
In addition to these properties, transaction isolation levels are used
to control the interaction between concurrent transactions. The
four standard isolation levels are:
Read Uncommitted: This is the lowest level of isolation, where a
transaction can see uncommitted changes made by other
transactions. This can result in dirty reads, non-repeatable reads,
and phantom reads.
Read Committed: In this isolation level, a transaction can only see
changes made by other committed transactions. This eliminates
dirty reads but can still result in non-repeatable reads and
phantom reads.
Repeatable Read: This isolation level guarantees that a transaction
will see the same data throughout its duration, even if other
transactions commit changes to the data. However, phantom
reads are still possible.
Serializable: This is the highest isolation level where a transaction is
executed as if it were the only transaction in the system. All
transactions must be executed sequentially, which ensures that
there are no dirty reads, non-repeatable reads, or phantom reads.
The choice of isolation level depends on the specific requirements
of the application. Higher isolation levels offer stronger data
consistency but can also result in longer lock times and increased
contention, leading to decreased concurrency and performance.
Lower isolation levels provide more concurrency but can result in
data inconsistencies.

WHAT IS SCHEDULE?
In a Database Management System (DBMS), a schedule refers to
the order in which transactions are executed or the sequence of
operations applied to a database. It defines the timeline of
transaction execution, specifying when each transaction begins
and completes its operations. Schedules are crucial for managing
concurrent access to data by multiple transactions, ensuring data
consistency and integrity, and optimizing system performance.

6|Page
There are two main types of schedules in DBMS:
Serial Schedule: In a serial schedule, transactions are executed
one after the other. This ensures simplicity and consistency but
may lead to underutilization of system resources.
Concurrent Schedule: Concurrent schedules allow multiple
transactions to execute simultaneously, improving system
efficiency. However, managing concurrency introduces
challenges such as avoiding conflicts and maintaining data
consistency.
Serial schedules are recoverable, meaning that the system can
restore to a consistent state in case of transaction failures.
Techniques like logging and checkpoints are employed to ensure
recoverability. Concurrent schedules can be further divided into
cascadeless and strict schedules based on recoverability:
Cascadeless Schedule: A schedule is cascadeless if it does not
result in a cascading rollback of transactions after a failure. In a
cascade-less schedule, a transaction that has read uncommitted
data from another transaction cannot commit before that
transaction commits. If a transaction fails before committing, its
updates must be rolled back, but any transactions that have read
its uncommitted data need not be rolled back.
Strict Schedule: A schedule is strict if it is both recoverable and
cascades. In a strict schedule, a transaction that has read
uncommitted data from another transaction cannot commit
before that transaction commits, and a transaction that has
updated the database must commit before any other transaction
reads or writes the same data. If a transaction fails before
committing, its updates must be rolled back, and any transactions
that have read its uncommitted data must also be rolled back.
Choosing the appropriate schedule type depends on the specific
requirements of the system, including performance, concurrency,
and recoverability.

7|Page
DIFFERENCE BETWEEN SERIAL SCHEDULE
AND SERIALIZABLE SCHEDULE

Serial Schedule Serializable Schedule

In Serial schedule, transactions will be In Serializable schedule transaction are


executed one after other. executed concurrently.

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

In serial schedule only one transaction In Serializable schedule multiple


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

Serial schedule takes more time for


In Serializable schedule execution is fast.
execution.

CONCURRENCY CONTROL IN DBMS


Concurrency control ensures proper execution and
synchronization of multiple concurrent transactions or requests
accessing a shared database or resource, preventing conflicts
and maintaining data consistency. It employs various techniques
to manage concurrent access to shared resources and is
particularly important in data processing and analytics scenarios.
Concurrency control techniques include locking and timestamp-
based protocols. Locking guarantees exclusive use of data items
to a current transaction by acquiring a lock before accessing the
data items and releasing the lock after completion. There are two
types of locks: shared and exclusive. Shared locks allow
transactions to read data item values, while exclusive locks allow
transactions to read and write data item values.

8|Page
Timestamp-based protocols order transactions based on their
timestamps, with older transactions having higher priority. The
Timestamp Ordering Protocol uses system time or a logical counter
to generate timestamps and maintain the order of transactions
based on their creation time. This protocol ensures serializability,
freedom from deadlock, and cascade-free schedules, but may
not always result in recoverable or cascade-free schedules.
Concurrency control is essential to maintain data integrity and
consistency in multi-user systems, such as ATM machines, where
multiple users need to access shared resources simultaneously. It
helps to prevent problems like lost updates, uncommitted
dependency (dirty read), and inconsistent retrievals, which can
lead to incorrect data and inconsistencies in the database.

CONCURRENCY CONTROL PROBLEMS


Concurrency control problems in database systems refer to issues
that arise when multiple transactions attempt to access and
modify the same data simultaneously. These problems can lead to
inconsistencies, incorrect results, or even data loss. Some common
concurrency control problems include:
Lost Update Problem (W-W Conflict): This problem occurs when
two transactions modify the same data, and one transaction
overwrites the changes made by the other. As a result, the update
made by the first transaction is lost.
Dirty Read Problem (W-R Conflict): In this scenario, a transaction
reads data that has been modified by another transaction but
has not yet been committed. This can lead to incorrect results, as
the data being read may not be consistent with the changes
made by the other transaction.
Unrepeatable Read Problem (W-R Conflict): This problem occurs
when a transaction reads data from a database, and another
transaction modifies the data before the first transaction
completes its read operation. This can result in the first transaction
reading different data on subsequent reads.

9|Page
To address these concurrency control problems, database
management systems use various techniques, such as:
Lock-based protocols: These protocols require every transaction
to request an appropriate lock before data read or write
operations. Locks can be shared (allowing multiple transactions to
read the data) or exclusive (preventing other transactions from
reading or writing the data).
Timestamp-based protocols: In this approach, transactions are
executed based on the timestamps assigned to them. Older
transactions are given priority, ensuring that the transactions
execute in an ordered manner.
Multiversion concurrency control (MVCC): This technique
eliminates read and write operation conflicts arising during
concurrent transactions. It is typically used with other concurrency
control mechanisms for better results.
Database performance monitoring tools can also help determine
the concurrency capabilities of your database system and
analyse the queries processed simultaneously by your database
application. This can assist in optimizing database performance
and detecting and resolving issues related to poor database
concurrency and throughput.

CONCURRENCY CONTROL PROTOCOL


Concurrency control protocols are the set of rules which are
maintained in order to solve the concurrency control problems in
the database. It ensures that the concurrent transactions can
execute properly while maintaining the database consistency. The
concurrent execution of a transaction is provided with atomicity,
consistency, isolation, durability, and serializability via the
concurrency control protocols.
 Locked based concurrency control protocol
 Timestamp based concurrency control protocol

10 | P a g e
Locked based Protocol
In locked based protocol, each transaction needs to acquire
locks before they start accessing or modifying the data items.
There are two types of locks used in databases.
Shared Lock : Shared lock is also known as read lock which allows
multiple transactions to read the data simultaneously. The
transaction which is holding a shared lock can only read the data
item but it can not modify the data item.
Exclusive Lock : Exclusive lock is also known as the write lock.
Exclusive lock allows a transaction to update a data item. Only
one transaction can hold the exclusive lock on a data item at a
time. While a transaction is holding an exclusive lock on a data
item, no other transaction is allowed to acquire a
shared/exclusive lock on the same data item.
There are two kind of lock based protocol mostly used in
database:
Two Phase Locking Protocol : Two phase locking is a widely used
technique which ensures strict ordering of lock acquisition and
release. Two phase locking protocol works in two phases.
Growing Phase : In this phase, the transaction starts acquiring locks
before performing any modification on the data items. Once a
transaction acquires a lock, that lock can not be released until
the transaction reaches the end of the execution.
Shrinking Phase : In this phase, the transaction releases all the
acquired locks once it performs all the modifications on the data
item. Once the transaction starts releasing the locks, it can not
acquire any locks further.
Strict Two Phase Locking Protocol : It is almost similar to the two
phase locking protocol the only difference is that in two phase
locking the transaction can release its locks before it commits, but
in case of strict two phase locking the transactions are only
allowed to release the locks only when they performs commits.

11 | P a g e
Timestamp based Protocol
In this protocol each transaction has a timestamp attached to it.
Timestamp is nothing but the time in which a transaction enters
into the system.
The conflicting pairs of operations can be resolved by the
timestamp ordering protocol through the utilization of the
timestamp values of the transactions. Therefore, guaranteeing
that the transactions take place in the correct order.

ADVANTAGES CONCURRENCY CONTROL

Advantages of concurrency control in DBMS include:


1. Decreased waiting time: Concurrency control allows multiple
transactions to be executed simultaneously, reducing the
waiting time for each transaction to complete.
2. Increased response time: By allowing transactions to
proceed without waiting for locks or resources, concurrency
control can improve the responsiveness of the system.
3. Improved resource utilization: Concurrency control enables
better resource utilization by allowing multiple transactions to
use the same database simultaneously.
4. Increased system performance and efficiency: Concurrency
control can lead to improved system performance and
efficiency by reducing the time taken to execute
transactions.
5. Support for high levels of concurrency and isolation:
Concurrency control allows transactions to work on different
copies of the data without interfering with each other,
supporting high levels of concurrency and isolation.
6. Flexible and adaptive tuning: The level of conflict detection
and resolution can be adjusted according to the workload
and application requirements, allowing for more flexible and
adaptive tuning of the system

12 | P a g e
DISADVANTAGES CONCURRENCY
CONTROL

1. Additional overhead: Implementing concurrency control


requires additional overhead, such as acquiring and
releasing locks on database objects, which can lead to
slower performance and increased resource consumption.
2. 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.
3. Reduced concurrency: Concurrency control can limit the
number of users or applications that can access the
database simultaneously, leading to reduced concurrency
and slower performance in systems with high levels of
concurrency.
4. Complexity: Implementing concurrency control can be
complex, particularly in distributed systems or in systems with
complex transactional logic.
5. Inconsistency: In some cases, concurrency control can lead
to inconsistencies in the database, such as uncommitted
dependencies or dirty reads

13 | P a g e
CONCULSION OF
CONCURRENCY CONTROL

Concurrency control ensures transaction atomicity, isolation,


consistency, and serializability. Concurrency control issues occur
when many transactions execute randomly. A dirty read happens
when a transaction reads data changed by an uncommitted
transaction. When two transactions update data simultaneously,
the Lost Update issue occurs. Lock-based protocol prevents
incorrect read/write activities. Timestamp-based protocols
organise transactions by timestamp.
Concurrency control is a crucial mechanism in DBMS that ensures
data integrity and safety by managing simultaneous transactions.
It is designed to prevent data inconsistencies and maintain data
consistency in a multi-user environment. There are two main types
of concurrency control mechanisms: pessimistic and optimistic.
Pessimistic concurrency control is conservative and delays
transactions if they conflict with other transactions, while optimistic
concurrency control assumes that conflicts are rare and allows
transactions to proceed without imposing delays. Both pessimistic
and optimistic concurrency control mechanisms have their
strengths and weaknesses, and the choice between them
depends on the specific requirements of the system.
In summary, concurrency control is essential in DBMS to manage
simultaneous transactions, prevent data inconsistencies, and
ensure data integrity. It is a crucial function that enables
concurrent access to data while maintaining data consistency,
integrity, and performance.

14 | P a g e
BIBLOGRAPHY

For successfully completing my project file. I have taken help


from the following websites:
 www.google.com
 www.geeksforgeeks.org
 www.javappoint.com
 www.scaler.com
 www.vldb.org

THANK YOU

15 | P a g e

You might also like