Chapter One

Transaction Management and

Concurrency Control
 Basic Outline
• Transaction
• transaction schedule
• Concept of Serializability
• Concurrency Control
• Problems of Concurrent transaction
• Concurrency Control Mechanism
• Database Recovery
Transaction
• A transaction is action, or series of actions, carried out by
user or application, which accesses or updates contents of
database.
• A transaction is a unit of program execution that accesses
and possibly updates various data items.
• Transactions access data using read and write operations.
• Transaction in Database Management Systems (DBMS) can
be defined as a set of logically related operations.
cont.
• It is the result of a request made by the user to access the
contents of the database and perform operations on it.
• It consists of various operations and has various states in its
completion journey.
• It also has some basic properties that must be followed to keep
the consistency of database .
cont.
• A transaction Can have one of two outcomes:
• Success - transaction commits -------> database reaches a new
consistent state.
• Failure - transaction aborts,-----> database must be restored to
consistent state before it started.. Such a transaction is rolled
back or undone.
• Committed transaction cannot be aborted.
• Aborted transaction that is rolled back can be restarted later.
transction operation
•A user can make different types of requests to access and
modify the contents of a database.
• A transaction includes one or more database access operations
such as insertion, deletion, modification, or retrieval
operations.
• The database operations that form a transaction can either be
embedded within an application program or they can be
specified interactively via a high- level query language such as
SQL.
Transaction Schedule
• A schedule is defined as an execution sequence of
transactions.
• A schedule maintains the order of the operation in each
individual transaction.
• A schedule is the arrangement of transaction operations.
• A schedule may contain a set of transactions.
• We already know that a transaction is a set of operations.
• To run transactions concurrently, we arrange or schedule their
operations in an interleaved fashion.
cont.
• When multiple transaction requests are made at the same time,
we need to decide their order of execution.
• Thus, a transaction schedule can be defined as a
chronological order of execution of multiple transactions.
• is a process of lining the transactions and executing them one
by one.
types of schedule
• there are two types of schedule
time Transaction1 Transaction 2
• Serial Schedule
t1 read(x);
• non serial schedule x=x-n;
write(x);
• Serial Schedule: In this kind of schedule, read(y);
y=y+n;
• when multiple transactions are to be write(y);

executed, they are executed serially. t2 read(x)

x=x+n
• that is at one time only one transaction write(x)
is executed while others wait for the
execution of the current transaction to
be completed.
cont.
• This ensures consistency in the database as transactions do
not execute simultaneously.
• But, it increases the waiting time of the transactions , which
results lowers the throughput of the system, that is number of
transactions executed per time.
• To improve the throughput of the system, another kind of
schedule(non serial schedule) are used.
• which has some more strict rules which help the database to
remain consistent even when transactions execute
simultaneously.
cont.
• Non-Serial Schedule:
• reduce the waiting time of transactions and
• improve the system efficiency.
• Non-Serial Schedule: allow multiple transactions to start before a
transaction is completely executed.
• This may sometimes result in inconsistency and errors in database
operation.
• So, these errors are handled with specific algorithms to maintain the
consistency of the database and improve CPU throughput as well.
• Serial Schedules are also sometimes referred to as parallel
schedules as transactions execute in parallel in this kind of
schedules.
 cont.
time T1 T2
• If interleaving of operations is allowed,
then there will be non-serial schedule. t1 read(x)
x=x-n
• It contains many possible orders in which
the system can execute the individual t2 read(x)
operations of the transactions. x=x+m

• In the given table are the non-serial t3 write(x)

read(y)
schedules. It has interleaving of
operations. t4 write(x)
t5 y=y+m
write(y)
Serializable
• Serializability in DBMS is the property of a nonserial schedule that
determines whether it would maintain the database consistency or
not.
• The nonserial schedule which ensures that the database would be
consistent after the transactions are executed in the order
determined by that schedule is said to be Serializable Schedules.
• The serial schedules always maintain database consistency as a
transaction starts only when the execution of the other transaction
has been completed under it.
• Thus, serial schedules are always serializable.
• A transaction is a series of operations, so various states occur in its
completion journey.
Transaction States and State Transition Diagram
and Additional Operations
• Active
• Partially Committed
• Commited
• Failed
• Aborted
Active : transaction state
• It is the first stage of any transaction when it has begun to
execute.
• The execution of the transaction takes place in this state.
• Operations such as insertion, deletion, or updation are
performed during this state.
• During this state, the data records are under manipulation
and they are not saved to the database, rather they remain
somewhere in a buffer in the main memory.
 Partially Committed:transaction state
• This state of transaction is achieved
• when it has completed most of the operations and is
executing its final operation.
• It can be a signal to the commit operation, as after the final
operation of the transaction completes its execution, the data
has to be saved to the database through the commit
operation.
• If some kind of error occurs during this state, the transaction
goes into a failed state, else it goes into the Committed
state.
Commited:transaction state
• This state of transaction is achieved
• when all the transaction-related operations have been
executed successfully along with the Commit operation.
• that is data is saved into the database after the required
manipulations in this state.
• This marks the successful completion of a transaction.
cont.
• Failed:
• If any of the transaction-related operations cause an error during
the active or partially committed state, further execution of the
transaction is stopped and it is brought into a failed state.
• Here, the database recovery system makes sure that the
database is in a consistent state.
• Aborted
• If the error is not resolved in the failed state,
• then the transaction is aborted and a rollback operation is
performed to bring database to the the last saved consistent state.
• When the transaction is aborted, the database recovery module
either restarts the transaction or kills it.
Properties of Transaction
• Transactions deal with accessing and modifying the
contents of the database.
• They must have some basic properties which helps
• to maintain the consistency and integrity of the database
before and after the transaction.
• Transactions have 4 basic properties, namely, Atomicity,
Consistency, Isolation, and Durability.
• Generally, these are referred to as ACID properties of
transactions in DBMS.
ACID Propertiesof Transaction
• Atomicity: A transaction is an atomic unit of processing;
• it is either performed in its entirety or not performed at all.
• Consistency preservation:
• A correct execution of the transaction must take the database from
one consistent state to another.
• Isolation:
• A transaction should not make its updates visible to other transactions
until it is committed;
• this property, when enforced strictly, solves the temporary update
problem and makes cascading rollbacks of transactions unnecessary .
• Durability or permanency:
• Once a transaction changes the database and then the changes are committed,
these changes must never be lost because of subsequent failure.
Concurrent transaction
• concurrent is Two or more events are happening at the same time.
• It is allowing multiple users to access the data contained within a
database at the same time.
• When many transactions are executed simultaneously then we call
them concurrent transactions.
• Concurrency is required to increase time efficiency.
• If there are many transactions which are trying to access the same
data, then inconsistency may arises.
• Concurrency control is required to maintain consistency of data.
• In order to run transactions concurrently, we interleave their
operations.
• that meas each transaction gets a share of computing time.
Why Concurrency Control is needed:
• Transactions submitted by the various users may execute
concurrently and may access and update the same database
items,If this concurrent execution is uncontrolled,
• it may lead to problems, such as an inconsistent database.
• such problems can occur when concurrent transactions execute
in an uncontrolled manner.
• Inconsistent database problem
• Lost update problem. ( WW conflict)
• Dirty read / temporary update problem. ( WR conflict)
• Incorrect summary problem. (RW conflict)
loss update problem time T1 T2 X=10
• ocurres when T1 T2
• One transaction does some t1 read(x) 10
changes and another transaction x=x-5 5
deletes those changes.
• One transaction nullifies the t2 read(x) 10
updates of another transaction. x=x+5 15
• Two transactions T1 and T2 read,
t3 write(x) 5
modify, write to the same data item
in an interleaved fashion for which t4 write(x) 15
an incorrect value is stored in x.
• T2 reads the value of X before T1
The final value of x is 15, which is
changes it hence the updated incorrect.
value resulting from T1 is lost.
Temporary Update Problem (Write-Read Conflict):
• This problem occurs when Time T1 T2 item X=80

one transaction updates a

T1 T2
database item and then the
transaction fails for some t1 read(X) 80
x=x-5 75
reason(). write(x) 75
• The updated item is accessed t2 read(x) 75
by another transaction before x=x+10 85
write(x) 85
it is changed back to its
original value. t3 read(x) 85
The final value of x is 85, which is incorrect.
cont.
• The above table shows an example where T1 updates item X and
then fails before completion.
• So the system must change X back to its original value.
• Transaction T2 reads the temporary value of X, which will not be
recorded permanently in the database because of the failure of T1.
• The value of item X that is read by T2 is called dirty data, because
it has been created by a transaction that has not completed and
committed yet;
• hence, this problem is also known as the dirty read problem or
temporal update problem
Incorrect Summary Problem
• If one transaction is calculating an aggregate summary
function on a some records while other transactions are
updating some of these records,
• the aggregate function may calculate some values before
they are updated and others after they are updated.
• consider the following T1 T2 x=20 , n=5 y=15
situation: • sum=0
read(x)
• Suppose that a transaction T2 is sum=sum+x

calculating the total number of read(x)

x=x-n
reservations on all the flights. write(x)
• the result of T2 will be off by an read(x)
sum=sum+x
amount N because,T2 reads the read(y)
value of X after N seats have sum=sum+y
been Subtracted from it but read(y)
reads the value of Y before y=y+n
write(y)
those N seats have been added
T2 read 20 after 5 is substracted and reads 15 before
to it. 5 is added .wrong summary is the rsult off by 5
Concurrency Control
• is a Processes of managing simultaneous operations on the database
without having them interfere with one another.

• Concurrency Control is required

• for prevents interference when two or more users are accessing

database simultaneously and at least one is updating data.
• Although two transactions may be correct in themselves, interleaving of
operations may produce an incorrect result.
• for controlling and managing the concurrent execution of database
operations and for avoiding the inconsistencies in the database.
Concurrency Control Protocols
• The concurrency control protocols ensure the atomicity,
consistency, isolation, durability and serializability of the
concurrent execution of the database transactions.
• Therefore, these protocols are categorized as
• Lock Based Concurrency Control Protocol
• Time Stamp Concurrency Control Protocol
• Validation Based Concurrency Control Protocol
Lock Based Concurrency Control 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: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.
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.
Time Stamp Concurrency Control Protocol
• The Timestamp Ordering Protocol is
• used to order the transactions based on their Timestamps.
• Timestamp is a unique identifier created by the DBMS to
identify the relative starting time of a transaction.
• time stamping is a method of concurrency control in which each
transaction is assigned a transaction timestamp.
• timestamp values are assigned in the order in which the
transactions are submitted to the system.
• So, a timestamp can be thought of as the transaction start time.
cont
• A transaction timestamp is increasing number, which is often based on the
system clock.
• The transactions are managed so that they appear to run in a timestamp
order.
• Timestamps can also be generated by incrementing a logical counter
every time a new transaction starts.
• Let's assume there are two transactions T1 and T2.
• Suppose the transaction T1 has entered the system at 007 times and
transaction T2 has entered the system at 009 times.
• T1 has the higher priority, so it executes first as it is entered the system
first.
• The timestamp ordering protocol also maintains the timestamp of last
'read' and 'write' operation on a data.
Validation Based Concurrency Control Protocol
• Validation is also known as optimistic concurrency control
technique.
• In the validation based protocol,
• the transaction is executed in the following three phases:
• Read phase:
• In this phase, the transaction T is read and executed.
• It is used to read the value of various data items and stores
them in temporary local variables.
• It can perform all the write operations on temporary
variables without an update to the actual database.
 cont.
• Validation phase:
• In this phase, the temporary variable value will be validated
against the actual data to see if it violates the serializability.
• Write phase: If the validation of the transaction is validated,
then the temporary results are written to the database or system
otherwise the transaction is rolled back.
Database Recovery
• Database Recovery: is the process of restoring the database
to the most recent consistent state that existed just before
the failure .
• Database Recovery: important in managing a database system
• purpose of Database Recovery
• to bring the database into the last consistent state ,which existed prior
to the failure.
• to preserves transaction (ACID) properties
Database failure
• Failure 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
cont.
•Transaction failure: Transactions may fail because of incorrect input,
deadlock, incorrect synchronization.
•System failure/crash: System may fail because of addressing error,
application error, operating system fault, RAM failure, etc.
•Media failure/data transfer failure: Disk head crash, power
disruption, etc.
Database recovery techniques
• Database recovery techniques are used in database
management systems (DBMS) to restore a database to a
consistent state after a failure or error has occurred.
• The main goal of recovery techniques is to ensure data integrity
and consistency and finaly prevent data loss.
• Recovery is the rebuilding of a database or table space after a
problem such as media or storage failure, power interruption, or
application failure.
cont.
• If you have backed up your database, or individual table spaces,
you can rebuild them should they become damaged or corrupted
in some way.
• Database Systems like any other computer system, are subject to
failures but the data stored in them must be available as and when
required.
• When a database fails it must possess the facilities for fast
recovery.
• It must also have atomicity i.e. either transactions are completed
successfully and committed (the effect is recorded permanently in
the database) or the transaction should have no effect on the
database.
cont.
• There are three types of recovery techniques used in DBMS
• Rollback/Undo Recovery Technique
• Commit/Redo Recovery Technique
• Checkpoint Recovery Technique
 Rollback/Undo Recovery Technique
• is based on the principle of backing out or undoing the effects of a
transaction that has not been completed successfully due to a system
failure or error.

• This technique is accomplished by undoing the changes made by the

transaction using the log records stored in the transaction log.

• The transaction log contains a record of all the transactions that have been
performed on the database.

• The system uses the log records to undo the changes made by the failed
transaction and restore the database to its previous state.
Commit/Redo Recovery Technique
• is based on the principle of reapplying the changes made by a
transaction that has been completed successfully to the
database.

• This technique is accomplished by using the log records stored in

the transaction log to redo the changes made by the transaction
that was in progress at the time of the failure or error.

• The system uses the log records to reapply the changes made by
the transaction and restore the database to its most recent
Checkpoint Recovery Technique
• is used to reduce the recovery time by periodically saving the
state of the database in a checkpoint file.

• In the event of a failure, the system can use the checkpoint file
to restore the database to the most recent consistent state
before the failure occurred, rather than going through the entire
log to recover the database.
Thank You