Transaction Processing System

1. Transaction Processing
Prof. K ADISESHA (Ph. D)

2. Introduction
ACID Properties
States of Transaction
Conflict Schedule
Concurrency Control
2
Transaction Processing
Prof. K. Adisesha

3. Introduction
Prof. K. Adisesha (Ph. D)
3
Transaction in DBMS.
A transaction is made to change data in a database which can be done by inserting new
data, updating the existing data, or by deleting the data that is no longer required.
➢ Transactions are a set of operations that are used to perform some logical set of work.
➢ The protection of user's data even in case of a system failure marks as one of the major
advantages of database management system.
➢ 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.

4. Transaction
Prof. K. Adisesha (Ph. D)
4
Operations in Transaction:
Following are the low-level operations implemented in a DBMS transaction:
➢ Begin_Transaction: This specifies an indicator that defines the start of the execution of a
transaction.
➢ Read_Item or Write_Item: Here, the database operations can be enclosed with the
operations of the main memory as a portion of the transaction.
➢ End_Transaction: It is an indicator that defines the end of the transaction.
➢ Commit: It defines a signal to identify that the DBMS transaction has been absolutely
successful in its totality and will not be incomplete.
➢ Rollback: It defines a signal to identify that the DBMS transaction has been unsuccessful
and therefore all temporary deviations in the database are incomplete.

5. Transaction
Prof. K. Adisesha (Ph. D)
5
Operations in Transaction:
Transactions can be seen as a set of operations that are executed by the user program in
DBMS.
➢ When we go to withdraw money from ATM, we encounter the following set of operations:
❖ Transaction Initiated
❖ You have to insert an ATM card
❖ Select your choice of language
❖ Select whether savings or current account
❖ Enter the amount to withdraw
❖ Entering your ATM pin
❖ Transaction processes
❖ You collect the cash
❖ You press finish to end transaction

6. ACID Properties
Prof. K. Adisesha (Ph. D)
6
ACID Properties in DBMS:
DBMS is the management of data that should remain integrated when any changes are
done in it, there are four properties described in the database management system, which
are known as the ACID properties.
➢ ACID Properties defines for:

7. Transaction
Prof. K. Adisesha (Ph. D)
7
Transaction property:
The transaction has the four properties. These are used to maintain consistency in a
database, before and after the transaction.
➢ Property of Transaction are known as the ACID properties.
❖ Atomicity: It states that all operations of the transaction take place at once if not, the
transaction is aborted.
❖ Consistency: The consistent property of database states that every transaction sees a
consistent leaving a database in either its prior stable state or a new stable state.
❖ Isolation: It shows that the data which is used at the time of execution of a transaction
cannot be used by the second transaction until the first one is completed.
❖ Durability: The durability property is used to indicate the performance of the
database's consistent state. It states that the transaction made the permanent changes.

8. Transaction
Prof. K. Adisesha (Ph. D)
8
States of Transaction:
In a database, the transaction can be in one of the following states -
➢ Active State
➢ Partially Committed
➢ Failed State
➢ Aborted State
➢ Committed State
➢ Terminated State

9. Transaction
Prof. K. Adisesha (Ph. D)
9
States of Transaction:
In a database, the transaction can be in one of the following states -
➢ Active State: When the operations of a transaction are running then the transaction is
said to be active state.
➢ Partially Committed: After all the read and write operations are completed, the changes
which were previously made in the main memory are now made permanent in the
database.
➢ Failed State: If any operation during the transaction fails due to some software or
hardware issues, then it goes to the failed state .
➢ Aborted State: If the transaction fails during its execution, it goes from failed state to
aborted state and because in the previous states all the changes were only made in the
main memory, these uncommitted changes are either deleted or rolled back.

10. Transaction
Prof. K. Adisesha (Ph. D)
10
States of Transaction:
In a database, the transaction can be in one of the following states -
➢ Committed State: If the transaction completes all sets of operations successfully, all the
changes made during the partially committed state are permanently stored and the
transaction is stated to be completed, thus the transaction can progress to finally get
terminated in the terminated state.
➢ Terminated State: If the transaction gets aborted after roll-back or the transaction comes
from the committed state, then the database comes to a consistent state and is ready for
further new transactions since the previous transaction is now terminated.

11. Transaction
Prof. K. Adisesha (Ph. D)
11
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.
➢ Serial Schedule: The serial schedule is a type of schedule where one transaction is
executed completely before starting another transaction. In the serial schedule, when the
first transaction completes its cycle, then the next transaction is executed..
➢ Non-serial Schedule: If interleaving of operations is allowed, then there will be non-serial
schedule. It contains many possible orders in which the system can execute the individual
operations of the transactions.
➢ Serializable schedule: The serializability of schedules is used to find non-serial schedules
that allow the transaction to execute concurrently without interfering with one another.

12. Transaction
Prof. K. Adisesha (Ph. D)
12
Testing of Serializability:
Serialization Graph is used to test the Serializability of a schedule.
➢ Conflict Serializable Schedule: A schedule is called conflict serializability if after swapping of
non-conflicting operations, it can transform into a serial schedule.
➢ The two operations become conflicting if all conditions satisfy:
❖ Both belong to separate transactions.
❖ They have the same data item.
❖ They contain at least one write operation.
➢ Conflict Equivalent: In the conflict equivalent, one can be transformed to another by swapping
non-conflicting operations.
❖ Two schedules are said to be conflict equivalent if and only if:
❖ They contain the same set of the transaction.
❖ If each pair of conflict operations are ordered in the same way.

13. Transaction
Prof. K. Adisesha (Ph. D)
13
Recoverability of Schedule:
Sometimes a transaction may not execute completely due to a software issue, system crash
or hardware failure. In that case, the failed transaction has to be rollback.
➢ But some other transaction may also have used value produced by the failed transaction.
So we also have to rollback those transactions.
❖ Irrecoverable schedule: The schedule with two transactions Ti,&Tj, will be
irrecoverable if Tj reads the updated value of Ti and Tj committed before Ti commit.
❖ Recoverable with cascading rollback: The schedule will be recoverable with
cascading rollback if Tj reads the updated value of Ti. Commit of Tj is delayed till
commit of Ti.

14. Transaction Failure
Prof. K. Adisesha (Ph. D)
14
Failure Classification:
Failure in terms of a database can be defined as its inability to execute the specified
transaction or loss of data from the database.
➢ In DBMS 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. .
➢ A failure in DBMS can be classified as:
❖ Transaction failure
❖ System crash
❖ Disk failure

15. Transaction Failure
Prof. K. Adisesha (Ph. D)
15
Transaction Failure:
If a transaction is not able to execute or it comes to a point from where the transaction
becomes incapable of executing further then it is termed as a failure in a transaction.
➢ Reason for a transaction failure in DBMS:
❖ Logical Error: The transaction can’t continue with its normal execution due to some
internal condition, like bad input, data not found, overflow or resource limit exceeded.
❖ System Error: The system has entered an undesirable state (for example deadlock) as
a result of which, a transaction can’t continue with its normal execution.
✓ For example– The system ends an operating transaction if it reaches a deadlock
condition or if there is an unavailability of resources.

16. Transaction Failure
Prof. K. Adisesha (Ph. D)
16
System Crash:
There is a hardware malfunction, or a bug in the database software or the operating
system, that causes the loss of the content of volatile storage.
➢ A system crash usually occurs when there is some sort of hardware or software
breakdown.
➢ Some other problems which are external to the system and cause the system to abruptly
stop or eventually crash include failure of the transaction, operating system errors, power
cuts, main memory crash, etc..
➢ The content of nonvolatile storage remains intact and is not corrupted..

17. Transaction Failure
Prof. K. Adisesha (Ph. D)
17
Disk Failure:
When a disk block loses its content due to a head crash or failure during a data transfer
operation.
➢ It occurs where hard-disk drives or storage drives used to fail frequently. It was a
common problem in the early days of technology evolution.
➢ Disk failure occurs due to the formation of bad sectors, disk head crash, and
unreachability to the disk or any other failure, which destroy all or part of disk storage.

18. Transaction Failure
Prof. K. Adisesha (Ph. D)
18
Log-Based Recovery:
The log is a sequence of records. Log of each transaction is maintained in some stable
storage so that if any failure occurs, then it can be recovered from there.
➢ If any operation is performed on the database, then it will be recorded in the log.
➢ But the process of storing the logs should be done before the actual transaction is applied
in the database.
➢ There are two approaches to modify the database:
❖ Deferred database modification: The deferred modification technique occurs if the
transaction does not modify the database until it has committed.
❖ Immediate database modification: The Immediate modification technique occurs if
database modification occurs while the transaction is still active.

19. Transaction Failure
Prof. K. Adisesha (Ph. D)
19
Deadlock in DBMS:
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.
➢ Deadlock Avoidance: Deadlock avoidance mechanism is used to detect any deadlock
situation in advance. A method like "wait for graph" is used for detecting the deadlock
situation but this method is suitable only for the smaller database.
❖ 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..

20. Concurrency Control
Prof. K. Adisesha (Ph. D)
20
Concurrency Control:
Concurrency Control is the management procedure that is required for controlling
concurrent execution of the operations that take place on a database.
➢ In a multi-user system, multiple users can access and use the same database at one time,
which is known as the concurrent execution of the database.
➢ It means that the same database is executed simultaneously on a multi-user system by
different users operation should not affect the other executing operations, thus
maintaining the consistency of the database.

21. Concurrency Control
Prof. K. Adisesha (Ph. D)
21
Concurrency Control Protocols:
The concurrency control protocols ensure the atomicity, consistency, isolation, durability
and serializability of the concurrent execution of the database transactions.
➢ These protocols are categorized as:
❖ Lock Based Concurrency Control Protocol
❖ Time Stamp Concurrency Control Protocol
❖ Validation Based Concurrency Control Protocol.

22. Concurrency Control
Prof. K. Adisesha (Ph. D)
22
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:
➢ 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.

23. Concurrency Control
Prof. K. Adisesha (Ph. D)
23
Timestamp Ordering Protocol:
The Timestamp Ordering Protocol is used to order the transactions based on their
Timestamps. The order of transaction is nothing but the ascending order of the
transaction creation.
➢ The priority of the older transaction is higher that's why it executes first. To determine the
timestamp of the transaction, this protocol uses system time or logical counter.
➢ The lock-based protocol is used to manage the order between conflicting pairs among
transactions at the execution time. But Timestamp based protocols start working as soon
as a transaction is created.
➢ The timestamp ordering protocol also maintains the timestamp of last 'read' and 'write'
operation on a data.

24. Concurrency Control
Prof. K. Adisesha (Ph. D)
24
Validation Based Protocol:
Validation phase 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.
➢ 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.

25. Concurrency Control
Prof. K. Adisesha (Ph. D)
25
Concurrency Control Problems:
There are multiple problems that can arise in concurrent transaction scenarios. Some of
the common problems are:
➢ Dirty Read: Dirty read or temporary update problems happen while there is an
incomplete transaction. In this scenario, the data element or item got updated by one
transaction and filed before completing it.
➢ Unrepeatable Read: Unrepeatable Read is the scenario where two or more read
operations read the same variable as different values and that value is modified by a
different transaction by writing operations.
➢ Phantom Read: Phantom read problem refers to the scenario where the Transaction reads
a variable once and when it tries to read the variable again it gets an error showing the
variable does not exist, as the variable is deleted by another transaction.

26. Concurrency Control
Prof. K. Adisesha (Ph. D)
26
Concurrency Control Problems:
There are multiple problems that can arise in concurrent transaction scenarios. Some of
the common problems are:
➢ Lost updates: Lost updates are the concurrency problem scenario where modification to
the variable done by a transaction is lost due to write operation by another transaction.
➢ Incorrect Summary: An incorrect Summary problem in concurrency control scenario
appears while a transaction applies an aggregate function to some of the variables while
another transaction tries to update the variable.

27. Discussion
Prof. K. Adisesha (Ph. D)
27
Queries ?
Prof. K. Adisesha
9449081542