Chapter 7
Chapter 7
Chapter 7
Transaction Processing
Prepared By:
Ms. Ayushi Gondaliya
Assistant Prof.
SRCOE, RAJKOT
Transaction Process
• A transaction is a unit of program execution that
accesses and possibly updates various data items.
• A transaction must see a consistent database.
• During transaction execution the database may be
temporarily inconsistent.
• When the transaction completes successfully (is
committed), the database must be consistent.
• After a transaction commits, the changes it has made to
the database persist, even if there are system failures.
• Multiple transactions can execute in parallel.
• Two main issues to deal with:
▪ Failures of various kinds, such as hardware failures
and system crashes
▪ Concurrent execution of multiple transactions
ACID Properties
Property of Transaction
◦ Atomicity
◦ Consistency
◦ Isolation
◦ Durability
States Of Transaction
Active state
◦ The active state is the first state of every transaction. In
this state, the transaction is being executed.
◦ For example: Insertion or deletion or updating a record is
done here. But all the records are still not saved to the
database.
Partially committed
◦ In the partially committed state, a transaction executes its
final operation, but the data is still not saved to the
database.
Committed
◦ A transaction is said to be in a committed state if it
executes all its operations successfully. In this state, all the
effects are now permanently saved on the database
system.
Failed state
◦ If any of the checks made by the database recovery
system fails, then the transaction is said to be in the
failed state.
◦ In the example of total mark calculation, if the
database is not able to fire a query to fetch the marks,
then the transaction will fail to execute.
Aborted
◦ If the transaction fails in the middle of the transaction
then before executing the transaction, all the
executed transactions are rolled back to its
consistent state.
◦ After aborting the transaction, the database recovery
module will select one of the two operations:
Re-start the transaction
Kill the transaction
Schedule
A series of operation from one transaction to
another transaction is known as schedule. It is
used to preserve the order of the operation in
each of the individual transaction.
1. Serial Schedule
The serial schedule is a type of schedule where
one transaction is executed completely before
starting another transaction.
For example: Suppose there are two transactions
T1 and T2 which have some operations. If it has no
interleaving of operations, then there are the following
two possible outcomes:
◦ Execute all the operations of T1 which was followed
by all the operations of T2.
◦ Execute all the operations of T2 which was followed
by all the operations of T1.
Let T1 transfer $50 from A to B, and T2 transfer 10% of the
balance from A to B.
T1 T2
Read(A)
Write(A)
Read(A)
Write(A)
Read(B)
Write(B)
Read(B)
Write(B)
So the serial schedule of the above given
schedule would look like this:
T1 T2
Read(A)
Write(A)
Read(B)
Write(B)
Read(A)
Write(A)
Read(B)
Write(B)
•At time t4, Transactions-Y rollbacks. So, it changes A's value back to
that of prior to t1.
•So, Transaction-X now contains a value which has never become part
of the stable database.
•Such type of problem is known as Dirty Read Problem, as one
transaction reads a dirty value which has not been committed.
3. Unrepeatable read.
Inconsistent Retrievals Problem is also known
as unrepeatable read. When a transaction
calculates some summary function over a set of
data while the other transactions are updating
the data, then the Inconsistent Retrievals
Problem occurs.
A transaction T1 reads a record and then does
some other processing during which the
transaction T2 updates the record. Now when
the transaction T1 reads the record, then the
new value will be inconsistent with the previous
value.
Transaction-X is doing the sum of all balance
while transaction-Y is transferring an amount
50 from Account-1 to Account-3.
Here, transaction-X produces the result of 550
which is incorrect. If we write this produced
result in the database, the database will become
an inconsistent state because the actual sum is
600.
Here, transaction-X has seen an inconsistent
state of the database.
Concurrency Control Protocol
Concurrency control protocols ensure
atomicity, isolation, and serializability of
concurrent transactions. The concurrency
control protocol can be divided into:
1. Lock based protocol
2. Time-stamp protocol
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:
◦ 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.
Two-phase Locking Protocol(2PL)
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 phase, the transaction cannot
demand any new locks. It only releases the
acquired locks.
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.
In the below example, if lock conversion is
allowed then the following phase can happen:
◦ Upgrading of lock (from S(a) to X (a)) is allowed in
growing phase.
◦ Downgrading of lock (from X(a) to S(a)) must be
done in shrinking phase.
The following way shows how unlocking and
locking work with 2-PL.
Transaction T1:
◦ Growing phase: from step 1-3
◦ Shrinking phase: from step 5-7
◦ Lock point: at 3
Transaction T2:
◦ Growing phase: from step 2-6
◦ Shrinking phase: from step 8-9
◦ Lock point: at 6
Time-stamp protocol
The most commonly used concurrency protocol is
the timestamp based protocol. This protocol uses
either system time or logical counter as a
timestamp.
Every transaction has a timestamp associated with
it, and the ordering is determined by the age of the
transaction.
The priority of the older transaction is higher that's
why it executes first.
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.
Time-stamp Ordering protocol
The timestamp-ordering protocol ensures
serializability among transactions in their
conflicting read and write operations.
This is the responsibility of the protocol system
that the conflicting pair of tasks should be
executed according to the timestamp values of
the transactions.
◦ The timestamp of transaction Ti is denoted as TS(Ti).
◦ Read time-stamp of data-item X is denoted by R-
TS(X).
◦ Write time-stamp of data-item X is denoted by W-
TS(X).
Basic Timestamp ordering protocol
works as follows:
1. Check the following condition whenever a
transaction Ti issues a Read (X) operation:
◦ If W_TS(X) >TS(Ti) then the operation is rejected.
◦ If W_TS(X) <= TS(Ti) then the operation is executed.
◦ Timestamps of all the data items are updated.
2. Check the following condition whenever a
transaction Ti issues a Write(X) operation:
◦ If TS(Ti) < R_TS(X) then the operation is rejected.
◦ If TS(Ti) < W_TS(X) then the operation is rejected and Ti
is rolled back otherwise the operation is executed.
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.
THANK YOU
Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.
Alternative Proxies: