B.

Tech
Course Name: Database Management System
Course Code:E2UC302B
Transaction in DBMS
 DBMS stands for Database Management System, which is a tool or software
used to create, delete, or manipulate the current database.
 Any logical work or set of works that are done on the data of a database is
known as a transaction.
 Logical work can be inserting a new value in the current database, deleting
existing values, or updating the current values in the database.
What does a Transaction mean in DBMS?
 Transaction in Database Management Systems (DBMS) can be
defined as a set of logically related operations.

 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 specific properties that must be followed to keep the
database consistent.
Example of Transaction
• In DBMS, we write the above 6 steps transaction like this:
• Lets say your account is A and your friend’s account is B, you are transferring
1000 from A to B, the steps of the transaction are:
• 1. R(A);
• 2. A = A - 10000;
• 3. W(A);
• 4. R(B);
• 5. B = B + 10000;
• 6. W(B);
• In the above transaction R refers to the Read operation and W refers to the
write operation.
Example of Transaction
 To complete a transaction, we have to follow some steps which make a transaction successful. For
example, we withdraw the cash from ATM is an example of a transaction, and it can be done in the
following steps:
• Initialization if transaction
• Inserting the ATM card into the machine
• Choosing the language
• Choosing the account type
• Entering the cash amount
• Entering the pin
• Collecting the cash
• Aborting the transaction
• So, in the same way, we have three steps in the DBMS for a transaction which are the
following:
• Read Data
• Write Data
• Commit
Operations of Transactions
 A user can make different types of requests to access and modify the
contents of a database. So, we have different types of operations
relating to a transaction. They are discussed as follows:
 (i) Read(X) A read operation is used to read the value of X from
the database and store it in a buffer in the main memory for further
actions such as displaying that value.

 (ii) Write(X) A write operation is used to write the value to the

database from the buffer in the main memory.
Operations of Transactions
 (iii) Commit This operation in transactions is used to maintain integrity in the database.
Due to some failure of power, hardware, or software, etc., a transaction might get
interrupted before all its operations are completed. This may cause ambiguity in the
database, i.e. it might get inconsistent before and after the transaction.

 To ensure that further operations of any other transaction are performed only after work of
the current transaction is done, a commit operation is performed to the changes made by a
transaction permanently to the database.

 iv) Rollback This operation is performed to bring the database to the last saved state when
any transaction is interrupted in between due to any power, hardware, or software failure.

 In simple words, it can be said that a rollback operation does undo the operations of
transactions that were performed before its interruption to achieve a safe state of the
database and avoid any kind of ambiguity or inconsistency.
Transaction property
ACID Properties
 There are four properties of a transaction that should be maintained during the
transaction.
 Atomicity: It means either a transaction will take place, or it will fail. There
will not be any middle state like partial completion.
 Consistency: The database should be consistent before and after the
transaction. Correctness and integrity constraints should be maintained during
the transaction.
 Isolation: This property means multiple transactions can occur at the same
time without affecting each other. If one transaction is occurring, then it should
not bring any changes in the data for the other transaction, which is occurring
concurrently.
 Durability: It means if there is a successful transaction, then all changes
should be permanent, so if there is any system failure, we will be able to
retrieve the updated data.
States of Transaction
 Active state 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. In the total mark calculation example, a final display
of the total marks step is executed in this state.

 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.
States of Transaction
 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.
 Aborted If any of the checks fail and the transaction has reached a
failed state then the database recovery system will make sure that the
database is in its previous consistent state. If not then it will abort or
roll back the transaction to bring the database into a consistent state.
 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.
Schedule
 A series of operations from one transaction to another transaction is known as a
schedule.
 It is used to preserve the order of the operation in each of the individual
transactions.
 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.
• 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:
1. Execute all the operations of T1 which was followed by all the operations of T2.
2. Execute all the operations of T1 which was followed by all the operations of T2.
• In the given (a) figure, Schedule A shows the serial schedule where T1 followed
by T2.
• In the given (b) figure, Schedule B shows the serial schedule where T2 followed
by T1.
 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.
 In the given figure (c) and (d), Schedule C and Schedule D are the
non-serial schedules. It has interleaving of operations.
Non-serial Schedule
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.
 It identifies which schedules are correct when executions of the
transaction have interleaving of their operations.
 A non-serial schedule will be serializable if its result is equal to the
result of its transactions executed serially.
Difference between Serial Schedule and
Serializable 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 schedule will be a conflict serializable if it is conflict equivalent
to a serial schedule.
• Conflicting Operations
• The two operations become conflicting if all conditions satisfy:
1. Both belong to separate transactions.
2. They have the same data item.
3. They contain at least one write operation.
View Serializability
 A schedule will view serializable if it is view equivalent to a serial
schedule.
 If a schedule is conflict serializable, then it will be view serializable.
 The view serializable which does not conflict serializable contains
blind writes.
View Equivalent
Two schedules S1 and S2 are said to be view equivalent if they satisfy the following conditions:
1. Initial Read An initial read of both schedules must be the same. Suppose two schedule S1 and S2. In
schedule S1, if a transaction T1 is reading the data item A, then in S2, transaction T1 should also read
A.
2. Updated Read : In schedule S1, if Ti is reading A which is updated by Tj then in S2 also, Ti should
read A which is updated by Tj.

3. Final Write
A final write must be the same between both the schedules. In schedule S1, if a transaction T1 updates
A at last then in S2, final writes operations should also be done by T1.
Recoverability of Schedule and Irrecoverable Schedule : Example
 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.
 Testing of Serializability

• Serialization Graph is used to test the Serializability of a schedule.

• Assume a schedule S. For S, we construct a graph known as
precedence graph. This graph has a pair G = (V, E), where V consists a
set of vertices, and E consists a set of edges. The set of vertices is used
to contain all the transactions participating in the schedule. The set of
edges is used to contain all edges Ti ->Tj for which one of the three
conditions holds:
1. Create a node Ti → Tj if Ti executes write (Q) before Tj executes read
(Q).
2. Create a node Ti → Tj if Ti executes read (Q) before Tj executes write
(Q).
3. Create a node Ti → Tj if Ti executes write (Q) before Tj executes write
(Q).
 If a precedence graph contains a single edge Ti → Tj, then all the instructions of Ti are executed before
the first instruction of Tj is executed.
 If a precedence graph for schedule S contains a cycle, then S is non-serializable. If the precedence graph
has no cycle, then S is known as serializable.
 Failure Classification
1. Transaction failure
• The transaction failure occurs when it fails to execute or when it reaches a point from where it can't go
any further. If a few transaction or process is hurt, then this is called as transaction failure.
• Reasons for a transaction failure could be -
1. Logical errors: If a transaction cannot complete due to some code error or an internal error condition,
then the logical error occurs.
2. Syntax error: It occurs where the DBMS itself terminates an active transaction because the database
system is not able to execute it. For example, The system aborts an active transaction, in case of
deadlock or resource unavailability.
2. System Crash
• System failure can occur due to power failure or other hardware or software
failure. Example: Operating system error.
• Fail-stop assumption: In the system crash, non-volatile storage is assumed not to be corrupted.
• 3. Disk Failure
• 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.
DBMS Concurrency Control
• Concurrency Control is the management procedure that is required for
controlling concurrent execution of the operations that take place on a
database.
 Concurrent Execution in DBMS
 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.
 While working on the database transactions, there occurs the requirement of using
the database by multiple users for performing different operations, and in that case,
concurrent execution of the database is performed.
 The thing is that the simultaneous execution that is performed should be done in an
interleaved manner, and no operation should affect the other executing operations,
thus maintaining the consistency of the database. Thus, on making the concurrent
execution of the transaction operations, there occur several challenging problems
that need to be solved.
Problems with Concurrent Execution : Lost Update Problems (W - W Conflict)

Consider the below diagram where two transactions TX and TY, are performed on the same
account A where the balance of account A is $300.
Problems with Concurrent Execution : Lost Update Problems (W - W Conflict)

 At time t1, transaction TX reads the value of account A, i.e., $300 (only read).
 At time t2, transaction TX deducts $50 from account A that becomes $250 (only deducted and
not updated/write).
 Alternately, at time t3, transaction TY reads the value of account A that will be $300 only
because TX didn't update the value yet.
 At time t4, transaction TY adds $100 to account A that becomes $400 (only added but not
updated/write).
 At time t6, transaction TX writes the value of account A that will be updated as $250 only, as
TY didn't update the value yet.
 Similarly, at time t7, transaction TY writes the values of account A, so it will write as done at
time t4 that will be $400. It means the value written by TX is lost, i.e., $250 is lost.
 Hence data becomes incorrect, and database sets to inconsistent.
 Dirty Read Problems (W-R Conflict)
 The dirty read problem occurs when one transaction updates an item of the database, and
somehow the transaction fails, and before the data gets rollback, the updated database item is
accessed by another transaction. There comes the Read-Write Conflict between both
transactions.
• For example: Consider two transactions TX and TY in the below diagram performing
read/write operations on account A where the available balance in account A is $300:
Dirty Read Problems (W-R Conflict)
 At time t1, transaction TX reads the value of account A, i.e., $300.
 At time t2, transaction TX adds $50 to account A that becomes $350.
 At time t3, transaction TX writes the updated value in account A, i.e.,
$350.
 Then at time t4, transaction TY reads account A that will be read as $350.
 Then at time t5, transaction TX rollbacks due to server problem, and the
value changes back to $300 (as initially).
 But the value for account A remains $350 for transaction T Y as committed,
which is the dirty read and therefore known as the Dirty Read Problem.
Unrepeatable Read Problem (W-R Conflict)
• Also known as Inconsistent Retrievals Problem that occurs when in a transaction, two different
values are read for the same database item.
• For example:
• Consider two transactions, TX and TY, performing the read/write operations on account A,
having an available balance = $300. The diagram is shown below:
• At time t1, transaction TX reads the value from account A, i.e., $300.
• At time t2, transaction TY reads the value from account A, i.e., $300.
• At time t3, transaction TY updates the value of account A by adding $100 to the
available balance, and then it becomes $400.
• At time t4, transaction TY writes the updated value, i.e., $400.
• After that, at time t5, transaction TX reads the available value of account A, and
that will be read as $400.
• It means that within the same transaction TX, it reads two different values of
account A, i.e., $ 300 initially, and after updation made by transaction T Y, it
reads $400. It is an unrepeatable read and is therefore known as the
Unrepeatable read problem.