UNIT-IV

TRANSACTIONS AND CONCURRENCY MANAGEMENT

A.LALITHA
ASSOCIATE PROFESSOR
AVINASH DEGREE COLLEGE
 Transaction
• A transaction is a logical unit of work which contains set of SQL statements.
Let’s take an example of a simple transaction. Suppose a bank employee transfers Rs 500 from A's account to
B's account. This is very simple and small transaction involves several low-level tasks.
A’s Account
Open_Account(A)
Old_Balance = A.balance
New_Balance = Old_Balance – 500
A.balance = New_Balance
Close_Account(A)
B’s Account
Open_Account(B)
Old_Balance = B.balance
New_Balance = Old_Balance + 500
B.balance = New_Balance
Close_Account(B)
 States of transaction
A transaction in a database can be in one of the following states −

Active − In this state, the transaction is being executed. This is the initial state of every transaction.

Partially Committed − When a transaction executes its final operation, it is said to be in a partially
committed state.

Failed − 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.

Aborted − If a transaction is failed to execute, then the database recovery system will make sure that the
database is in its previous consistent state. If not, it brings the database to consistent state by aborting or
rolling back the transaction.

Committed − 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.
 ACID PROPERTIES
• Atomicity, Consistency, Isolation, and Durability − commonly known as ACID properties − in order to
ensure accuracy, completeness, and data integrity.
• 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.

• Consistency − The database must remain in a consistent state after any transaction. If the database was in
a consistent state before the execution of a transaction, it must remain consistent after the execution of the
transaction as well.

• Durability − The database should be durable enough to hold all its latest updates even if the system fails
or restarts. If a transaction updates a chunk of data in a database and commits, then the database 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.

• 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.
 Concurrent Transaction and Concurrency Control?
• When multiple transactions are trying to access the same sharable resource, they are called concurrent
transactions.

• Concurrency control is the procedure in DBMS for managing simultaneous operations without conflicting with
each another. Concurrent access is quite easy if all users are just reading data. There is no way they can interfere
with one another. 

Concurrency control is a process to ensure that data is updated correctly and appropriately when multiple
transactions are concurrently executed in DBMS.

• Concurrency control is the problem of synchronizing concurrent transactions so that the following two
properties are achieved:

❖ The consistency of the DB is maintained.

❖ The maximum degree of concurrency of operations is achieved.

• In general, concurrency control is an essential part of Transaction Management. It is a mechanism for

correctness when two or more database transactions that access the same data or data set are executed
concurrently with time overlap. If multiple transactions are executed serially or sequentially, data is consistent in
a database.
• However, if concurrent transactions with interleaving operations are executed, some unexpected data and
inconsistent result may occur such as “lost update” problem, the “temporary update” problem and the “incorrect
summary” problem.
• The “lost update” problem relates to concurrent reads and updates to data in a system where read
transactions do not block write (update) transactions.
 SCHEDULES
A schedule is a process of grouping the transactions into one and executing them in a
predefined order.
Serial Schedules:
Schedules in which the transactions are executed non-interleaved, i.e., a serial schedule is
one in which no transaction starts until a running transaction has ended are called serial
schedules.
Example: Consider the following schedule involving two transactions T 1 and T2.where
R(A) denotes that a read operation is performed on some data item ‘A’ This is a serial
schedule since the transactions perform serially in the order T 1 —> T2
Non-Serial Schedule:
This is a type of Scheduling where the operations of multiple transactions are interleaved. This might lead to
a rise in the concurrency problem. The transactions are executed in a non-serial manner, keeping the end result
correct and same as the serial schedule.
• Parallel execution of transaction is allowed in the database only if there is any equivalence relation among
the transactions.
• There are three types of equivalence relation among the transactions – Result, view and Conflict
Equivalence.
Result Equivalence
If the two transactions generate same result after their execution then it is called as result equivalence.
For example, one transaction is updating the marks of Student X and the other transaction is to insert a new
student. Here both the transactions are totally independent and their order of execution does not matter. 
Whichever order they are executed, the result is the same. Hence it is called result equivalence transactions.
View Equivalence
Two schedules are said to be view equivalence, if the transaction in one schedule is same as the one in other.
That means, both the transactions in two schedules perform same tasks.
For example, say schedule1 has transaction to insert new students into STUDENT table and second schedule
has the transaction to maintain the old student records in a new table called OLD_STUDENT. In both the
schedules student details are inserted, but different tables (it does not matter if it is same table). Such schedules
are called as view equivalence schedule.
Conflict Equivalence
In this case both schedules will have different set of transactions, but they would be accessing same data and
one of the schedules will be inserting/updating the records. In this equivalence, both the schedules will have
conflicting set of transactions.
Above example of updating the marks of one student by one transaction and calculating the total marks at the
same time is a conflicting equivalence.
 LOCKS AND LOCKING PROTOCOL

What is Lock?
• A lock is a variable associated with a data item that describes the status of the item
with respect to possible operations that can be applied to it. Generally, there is one lock for
each data item in the database.
• Locks are used as a means of synchronizing the access by concurrent transactions to the
database item.
• There are two types of operations
– Read operation-It is used to retrieve the values
– Write operation-It is used to insert, update or delete the values.
A locking Protocol is a set of rules followed by all transactions while requesting and
releasing the locks.
 Types of Locks

1.Binary locks: A binary lock can have two states or values:

1. Locked or 1
2. Unlocked or 0

Lock_item: A transaction request access to an item by issuing a lock(X) operation. If

LOCK(X)=1, the transaction is forced to wait. If LOCK(X)=0, it is set to 1 and the
transaction is a load to access item X.
Unlock_item:After using the data item , the transaction issues an operation unlock(X),which
sets the operation LOCK(X) to 0.
2. Shared lock/Exclusive lock
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.
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.
 Two Phase Locking (2PL) Protocol

• Two-Phase locking protocol which is also known as a 2PL protocol. It is also called P2L. In this type of
locking protocol, the transaction should acquire a lock after it releases one of its locks.
• Growing Phase: In this phase transaction may obtain locks but may not release any locks.
• Shrinking Phase: In this phase, a transaction may release locks but not obtain any new lock.
 Deadlock
• A deadlock is a condition where two or more transactions are waiting indefinitely for one
another to give up locks. Deadlock is said to be one of the most feared complications in
DBMS as no task ever gets finished and is in waiting state forever.
• For example: In the student table, transaction T1 holds a lock on some rows and needs to
update some rows in the grade table. Simultaneously, transaction T2 holds locks on some rows
in the grade table and needs to update the rows in the Student table held by Transaction T1.
 Deadlock Detection
• In a database, when a transaction waits indefinitely to obtain a lock, then the DBMS should detect whether
the transaction is involved in a deadlock or not. The lock manager maintains a Wait for the graph to detect
the deadlock cycle in the database.
Wait for Graph
• This is the suitable method for deadlock detection. In this method, a graph is created based on the
transaction and their lock. If the created graph has a cycle or closed loop, then there is a deadlock.
• The wait for the graph is maintained by the system for every transaction which is waiting for some data
held by the others. The system keeps checking the graph if there is any cycle in the graph.
Wait-for graph work as follows:
1. Transaction T1 is waiting for Transaction T2 and T3
2. Transaction T3 is waiting for transaction T2
3. Transaction T2 is waiting for transaction T4
4. Transaction T4 is waiting for transaction T3
T2

T1 T4
The graph contains the cycle:
T2->T4->T3->T2.It means that transactions T2,T4 and T3
are all deadlocked. T3
 Deadlock Avoidance
• Aborting or restarting the transaction is waste of time and resources in transaction processing.
It is always better to avoid deadlock in a system before it affects the transaction fluency.
• In deadlock avoidance technique, the system dynamically considers every request and decides whether it
is safe to grant it at that point. The system requires additional information regarding the overall potential
use of each resource for each process, including resources available, resources allocated, future requests
and future releases by processes. Most deadlock avoidance algorithms need every process to tell in
advance the maximum number of resources of each type that it may need.
• A resource allocation graph is generally used to avoid deadlocks. No cycles in the resource allocation
graph indicates no deadlocks. If there are cycles, there may be a deadlock. If there is only one instance of
every resource, then a cycle implies a deadlock. Vertices of the resource allocation graph are resources and
processes.
• The resource allocation graph has request edges and assignment edges.
• An edge from a process to resource is a request edge and an edge from a resource to process is an
allocation edge. A calm edge denotes that a request may be made in future and is represented as a dashed
line. Based on calm edges, we can see if there is a chance for a cycle and then grant requests if the system
will again be in a safe state.
• In the below figure, Deadlock will occur if R2 is allocated to P2 and P1 request for Y.
 Deadlock Prevention
The technique deadlock prevention prevents the system from deadlock through transaction rollbacks. It chooses
rollback over waiting for the lock whenever the wait could cause a deadlock. Generally, the following two
deadlock prevention algorithms are used to prevent the deadlocks.
1. Wait-die
2. Wound-wait
Assume that a transaction T1 requests for a lock on a data item X. And, the data item X is already locked by
another transaction T2 in an incompatible mode. Deadlock prevention algorithms avoid the conditions that lead
to
2. Wait-die algorithm: Wait-die algorithm allows the older transaction to wait but kills the younger
transaction using time stamping method. The time stamping approach assigns a unique time stamp to
each transaction for scheduling concurrent transactions. The time stamp value decides the order in which
the transactions are submitted to the database. When a transaction T1 requests data item X held by
transaction T2, deadlock prevention protocol decides to allow T1 to wait or to rollback based on the
following conditions:
Condition 1: If timestamp of T1 is smaller than the timestamp of T2 (TS (Tl) < TS (T2)), 1. e., Tl started before
T2, then allow Tl to wait for T2 to release lock on X.
Condition 2: If timestamp of Tl is greater than the timestamp ofT2 (TS (Tl) >TS (T2)), i.e., Tl started after T2,
then rollback Tl. (Also, let Tl starts again with the same timestamp and request X in a random amount of time.)

2. Wound-wait algorithm: This algorithm allows the younger transaction to wait; but when an older
transaction requests an item held by a younger one, the older transaction forces the younger one to abort
and release the item. When a transaction Tl requests data item X held by transaction T2, deadlock prevention
protocol decides to allow Tl to wait or to rollback based on the following conditions:
Condition 1: If timestamp of Tl is greater than the timestamp of T2 (TS (Tl) > TS (T2)), i.e., Tl started after T2,
then allow Tl to wait for T2 to release lock on X.
Condition 2: If timestamp of Tl is smaller than the timestamp of T2 (TS (Tl) < TS (T2)), i.e., Tl started before
T2, then rollback T2, i.e., the data item requested by Tl will be preempted from T2 and T2 is rolled back.
deadlocking.
 OPTIMISTIC CONCURRENCY CONTROL (OCC)

• Optimistic concurrency control is based on assumption that the majority of the database operations do not conflict. The
transaction is executed without restrictions until it is committed and does not require any lock or time stamping
techniques.
• Optimistic concurrency improves performance because no locking of records is required, and locking of records
requires additional server resources. Optimistic locking is available on disk-based tables (secondary storage) only.
• Optimistic concurrency control divides a transaction into three phases.
They are:
• 1. Read phase
• 2. Validation phase
• 3. Writing phase
• During the read phase, a transaction reads database items, and performs writes on local buffers, with no checking taking
place;
• in validation phase, the system does synchronisation checking, and
• In the write phase, the changes are made permanent to the database. It assigns each transaction a unique timestamp at
the end of its read phase.
A transaction Ti is validated if one ofthe following conditions can be established for all transactions Tj with later timestamps:
• Transaction Ti completes its write phase before transaction Tj begins its read phase.
• Transaction Tj does not read any ofthe items written by Ti and transaction Ti finishes its write phase before transaction Tj
begins its write phase.
• Transaction Tj does not read or write any items written by Ti.
 Database Recovery
• Data recovery is the process of restoring data that has been lost, accidentally deleted, corrupted or made
inaccessible for any reason.
• A major responsibility of the database administrator is to prepare for the possibility of hardware, software,
network, process, or system failure.
• If such a failure affects the operation of a database system, database must return to normal operation as
quickly as possible. Recovery should protect the database and associated users from unnecessary
problems and avoid or reduce the possibility of having to duplicate work manually.
• Types of Database Failures There are many different types of failure that can affect database processing.
Several problems can destruct the normal operation of a database. They are:
 Types of Failures

1. Transaction Failures: This is a situation where a transaction fails to execute or when it reaches a point from
where it cannot go any further. This type of failure affects only few tables or processes. The reasons for this
type of failures can be:
(a) Logical errors: These types of errors occur when a transaction cannot continue with its normal execution
because of some internal condition such as invalid input, error in code, etc.
(b) System errors: These types oferrors occur when the system enters in some undesirable state such as
deadlock.

2. System Failures: Hardware, software failures, power failure, systemcrashes and operating system problems
comes in to this category. During a system failure, the contents ofthe main memory are lost. The data in the
secondary memory are not affected because of this crash as the database maintains lots ofintegrity checkpoints
to prevent the data loss from secondary memory.

3. Disk Failures: These are the problems with secondary storage (hard disks) like formation of bad sectors, disk
head crash, and unavailability of disk or failure during transaction, etc. These failures may happen at the time of
read or write operation ofthe transaction.
 Database Errors

There are many different types of failures that can affect database processing.

1. System errors: In case of system crash, the systems hang up and need to be rebooted. These failures occur
due to hardware malfunction or a bug in the database software or the operating system.

2. User error: Intentionally or unintentionally, a user may delete a row or dropping a table. Lack of end-user
training also may cause user errors.

3. Consistency errors: This error occur due to the inconsistent state of database caused may be due to wrong
execution of commands or in case of a transaction abort.

Back Up and Recovery techniques:

1.Periodic data and application backup
2. Proper backup identification
3. Convenient and safe backup storage
4. Physical protection of both hardware and software
5. Personal access control to the software of a database installation
6.Insurance coverage for the data in the database
 Database Security

Database security is the protection of information that is maintained in a database. It deals with
ensuring only the “right people” get the right to access the “right data”.
• Authentication: The process of verifying the identity of a user.
– Password Authentication
– Access control
• Authorization and views
– Types of views
• Read authorization
• Insert authorization
• Update authorization
• Delete authorization
• Encryption
THANK YOU