MODULE 6 - TRANSACTIONS

MANAGEMENT, CONCURRENCY Compiled by: Mrs. Jisha Tinsu

AND RECOVERY
29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 1
WHAT IS A
TRANSACTION?
▪A transaction is a single logical unit of
work that accesses and possibly modifies
the contents of a database. Transactions
access data using read and write
operations.
▪Example: A bank transfer operation
involves debiting an amount from one
account and crediting it to another.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 2

TRANSACTION STATES
▪A transaction goes through different states in its lifecycle. They are:
1. Active: The initial state when the transaction is being executed.
2. Partially Committed: When all operations of the transaction have been
executed, but the changes have not yet been written to the database.
3. Committed: When the transaction is successfully completed, and changes
are permanently saved to the database.
4. Failed: When the transaction cannot be completed due to some error (e.g.,
system crash, power failure).
5. Aborted: After a transaction fails, it must be rolled back to undo any
changes made during the transaction.
6. Terminated: The final state of the transaction, either committed or aborted.
29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 3
TRANSACTION STATES

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 4

TRANSACTION STATES
These are different types of Transaction States :
▪1. Active State – When the instructions of the transaction are running
then the transaction is in active state. If all the ‘read and write’
operations are performed without any error then it goes to the
“partially committed state”; if any instruction fails, it goes to the “failed
state”.
▪2. Partially Committed – After completion of all the read and write
operation the changes are made in main memory or local buffer. If the
changes are made permanent on the Database, then the state will
change to “committed state” and in case of failure it will go to the
“failed state”.
29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 5
TRANSACTION STATES
▪4. Aborted State – After having any type of failure the transaction goes from
“failed state” to “aborted state” and since in previous states, the changes are
only made to local buffer or main memory and hence these changes are
deleted or rolled-back.
▪5. Committed State – It is the state when the changes are made permanent on
the Database and the transaction is complete and therefore terminated in the
“terminated state”.
▪6. Terminated State – If there isn’t any roll-back or the transaction comes from
the “committed state”, then the system is consistent and ready for new
transaction and the old transaction is terminated.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 6

ACID PROPERTIES
▪Transactions must follow certain
properties to ensure data integrity
and consistency. These are called
ACID properties.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 7

ACID PROPERTIES
Atomicity
▪ The term atomicity defines that the data remains atomic.
▪ It means if any operation is performed on the data, either it should
be performed or executed completely or should not be executed at
all.
▪ It further means that the operation should not break in between or
execute partially.
▪ Ensures that all operations within a transaction are completed
successfully. If any operation fails, the entire transaction is aborted,
and changes are rolled back.
▪ Example: If a bank's debit operation fails, the credit operation is
also rolled back to avoid inconsistencies.
29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 8
 ACID PROPERTIES - ATOMICITY
▪Consider the following transaction T consisting of T1 and T2 : Transfer of 100 from
account X to account Y .

▪If the transaction fails after completion of T1 but before completion of T2(say, after
write(X) but before write(Y)), then the amount has been deducted from X but not
added to Y . This results in an inconsistent database state. Therefore, the transaction
must be executed in its entirety in order to ensure the correctness of the database
state.
29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 9
ACID PROPERTIES: CONSISTENCY
▪ Guarantees that a transaction will bring the database from one valid state
to another. No transaction should violate any of the integrity constraints of
the database.
▪ This means that integrity constraints must be maintained so that the database
is consistent before and after the transaction. It refers to the correctness of a
database. Referring to the example above, After a transaction, the sum of
credits and debits in a banking system should be consistent (no loss or
creation of money).
The total amount before and after the transaction must be maintained.
Total before T occurs = 500 + 200 = 700 .
Total after T occurs = 400 + 300 = 700 .
▪ Therefore, the database is consistent . Inconsistency occurs in case T1
completes but T2 fails.
29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 10
ACID PROPERTIES - ISOLATION
▪ The term 'isolation' means separation. In DBMS, Isolation is the property of a
database where no data should affect the other one and may occur
concurrently.
▪ In short, the operation on one database should begin when the operation on the
first database gets complete.
▪ It means if two operations are being performed on two different databases,
they may not affect the value of one another. In the case of transactions, when
two or more transactions occur simultaneously, the consistency should remain
maintained.
▪ Ensures that the intermediate state of a transaction is invisible to other
transactions. Transactions are isolated from one another to avoid interference.
▪ Example: Two transactions running concurrently should not affect each other's
operations.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 11

ACID PROPERTIES - DURABILITY
▪ This property ensures that once the transaction has completed
execution, the updates and modifications to the database are
stored in and written to disk and they persist even if a system
failure occurs.
▪ These updates now become permanent and are stored in non-
volatile memory. The effects of the transaction, thus, are never lost.
▪ Example: After a successful money transfer, the transaction logs
ensure that the transfer remains effective even after a sudden
system shutdown.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 12

 OPERATIONS OF TRANSACTION
▪Transaction Definition: A transaction is a unit of work that performs multiple database
operations (like read, write, update, delete). All operations must be executed entirely,
or none should be.
▪Operations of Transaction:
A user can make different types of requests to access and modify the contents of a
database. So, the different types of operations relating to a transaction 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.
▪ Such an operation is performed when a user wishes just to see any content of
the database and not make any changes to it. For example, when a user wants
to check his/her account’s balance, a read operation would be performed on
user’s account balance from the database.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 13

OPERATIONS OF TRANSACTION
ii. Write(X)
▪ A write operation is used to write the value to the database from the
buffer in the main memory.
▪ For a write operation to be performed, first a read operation is
performed to bring its value in buffer, and then some changes are made
to it, e.g., some set of arithmetic operations are performed on it
according to the user’s request, then to store the modified value back in
the database, a write operation is performed.
▪ For example, when a user requests to withdraw some money from his
account, his account balance is fetched from the database using a read
operation, then the amount to be deducted from the account is
subtracted from this value, and then the obtained value is stored back in
the database using a write operation.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 14

OPERATIONS OF TRANSACTION
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.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 15

OPERATIONS OF TRANSACTION
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.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 16

SERIALIZABILITY IN DBMS
▪Serializability is a concept in transaction management that helps
ensure the correctness of concurrent transactions. It provides a criterion
to decide whether a given schedule of transactions is safe and
equivalent to some serial execution.
▪1. What is Serializability?
▪A schedule is said to be serializable if it can be transformed into a
serial schedule (a schedule where transactions are executed one after
the other, without any overlap) by swapping non-conflicting
operations. A serial schedule is always considered correct because
transactions execute independently, without interfering with each other.
29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 17
WHAT IS A SCHEDULE?
▪A schedule is a series of operations from one or more transactions. A schedule can be
of two types:
▪Serial Schedule: When one transaction completely executes before starting another
transaction, the schedule is called a serial schedule. A serial schedule is always
consistent. e.g.; If a schedule S has debit transaction T1 and credit transaction T2,
possible serial schedules are T1 followed by T2 (T1->T2) or T2 followed by T1 ((T2-
>T1). A serial schedule has low throughput and less resource utilization.
▪Concurrent Schedule: When operations of a transaction are interleaved with
operations of other transactions of a schedule, the schedule is called a Concurrent
schedule. e.g.; the Schedule of debit and credit transactions shown in Table 1 is
concurrent. But concurrency can lead to inconsistency in the database. The above
example of a concurrent schedule is also inconsistent.
29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 18
SCHEDULE IN DBMS

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 19

EXAMPLE
T1’s buffer T2’s Buffer
T1 T2 Database
space Space

A=5000

R(A); A=5000 A=5000

A=5000 R(A); A=5000 A=5000

A=A-1000; A=4000 A=5000 A=5000

A=4000 A=A+500; A=5500

W(A); A=5500 A=4000

W(A); A=5500

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 20

CONCURRENCY PROBLEMS IN DBMS
▪Concurrency control is a very important concept of DBMS which ensures the
simultaneous execution or manipulation of data by several processes or user without
resulting in data inconsistency.
▪When multiple transactions execute concurrently in an uncontrolled or unrestricted
manner, then it might lead to several problems.
▪Such problems are called as concurrency problems.
▪The concurrency problems are-
▪Dirty Read Problem
▪Unrepeatable Read Problem
▪Lost Update Problem
▪Phantom Read Problem

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 21

CONCURRENCY CONTROL PROBLEMS
▪There are several problems that arise when numerous transactions are
executed simultaneously in a random manner.
▪The database transaction consist of two major operations “Read” and “Write”.
▪It is very important to manage these operations in the concurrent execution of
the transactions in order to maintain the consistency of the data.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 22

DIRTY READ PROBLEM(WRITE-READ 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
diagram performing read/write operations
on account A where the available balance in
account A is $300:

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 23

EXAMPLE - DIRTY READ
•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 TY as committed, which is the
dirty read and therefore known as the Dirty
Read Problem.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 24

 LOST UPDATE PROBLEM
▪This problem occurs when multiple transactions execute concurrently and
updates from one or more transactions get lost.
▪Consider the diagram where two transactions TX and TY, are performed on the
same account A where the balance of account A is $300.
•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.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 25

PHANTOM READ PROBLEM:
▪The phantom read problem occurs when a
transaction reads a variable once but when it tries
to read that same variable again, an error occurs
saying that the variable does not exist.
▪In the above example, once transaction 2 reads the
variable X, transaction 1 deletes the variable X
without transaction 2’s knowledge. Thus, when
transaction 2 tries to read X, it is not able to do it.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 26

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:

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 27

▪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. 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 updating made by transaction TY, it reads $400. It is
an unrepeatable read and is therefore known as the
Unrepeatable read problem.
▪Thus, in order to maintain consistency in the database and
avoid such problems that take place in concurrent
execution, management is needed, and that is where the
concept of Concurrency Control comes into role.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 28

AVOIDING CONCURRENCY PROBLEMS
▪ To ensure consistency of the database, it is very important to prevent the
occurrence of above problems.
▪Concurrency Control Protocols help to prevent the occurrence of above
problems and maintain the consistency of the database.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 29

WHY IS SERIALIZABILITY IMPORTANT?
▪In multi-user database environments, multiple transactions may be
executed concurrently.
▪If these transactions are not handled properly, they can lead to
inconsistencies.
▪Serializability ensures that even though the transactions are
executed concurrently, the final result is as if they were executed
serially, one after another.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 30

TYPES OF SERIALIZABILITY
▪There are two types of serializability in DBMS:
❑Conflict Serializability: A schedule is conflict-serializable if it can
be transformed into a serial schedule by swapping non-conflicting
operations.
❑View Serializability: A schedule is view-serializable if it produces
the same result as some serial schedule, considering the read and
write operations.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 31

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 32
CONFLICT SERIALIZABILITY
▪A schedule in DBMS is the sequence of transactions in the order of their execution.
▪Serial schedules have less resource utilization and low throughput. To improve it, two or more
transactions are run concurrently. However, concurrency of transactions may lead to
inconsistency in the database. To avoid this, we need to check whether these concurrent
schedules are serializable or not.
▪Serializability of non-serial schedules are of two types - conflict serializability and view
serializability.
▪A schedule is called conflict serializable 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.
▪Conflict Serializability in DBMS checks if a non-serial schedule is conflict serializable or not.
View Serializability checks if a schedule is view serializable or not. If a schedule is a view
equivalent to a Serial Schedule, it is said to be view serializable.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 33

CONFLICTING OPERATIONS
▪Conflict serializability is based on the concept of conflicts between operations.
▪A pair of operations are said to be conflicting operations if they follow the set
of conditions given below:
1. Each operation is a part of different transactions.
2. Both operations are performed on / access the same data item.
3. At least One of the performed operation is a write operation.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 34

CONFLICTING OPERATIONS
▪Let's consider two different transactions, Ti and Tj. Then considering the above
conditions, the following table follows:

Transaction i Transaction j IsConflicting??

Readi (X) Readj (X) Non-conflicting

Readi (X) Writej (X) Conflicting

Writei (X) Readj (X) Conflicting

Writei (X) Writej (X) Conflicting

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 35

EXAMPLE Transaction 1 Transaction 2
▪In the alongside schedule, we can notice that: R1(A) W2(B)
•W1(A) and R2(A) are part of different transactions. W1(A)
•Both apply to the same data item, i.e., A. R2(A)
R1(B) W2(A)
•W1(A) is a write operation.
▪W1(A) and R2(A) are conflicting operations as they satisfy all the above conditions.
▪Similarly, W1(A) and W2(A) are conflicting operations as they are part of different
transactions working on the same data item, and one of them is the write operation.
▪W1(A) and W2(B) are non-conflicting operations as they work on different data items and
thus do not satisfy all the given conditions.
▪R1(A) and R2(A) are non-conflicting operations as none of them is a write operation and thus
does not satisfy the third condition.
▪W1(A) and R1(A) are non-conflicting as they belong to the same transactions and thus do not
satisfy the first condition.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 36

CONFLICT EQUIVALENT
▪If a schedule gets converted into another schedule by swapping the non-conflicting
operations, they are said to be conflict equivalent schedules.
▪Checking Whether a Schedule is Conflict Serializable Or Not
▪A non-serial schedule gets checked for conflict serializability using the following steps:
1. Figure out all the conflicting operations and enlist them.
2. Create a precedence graph. For every transaction in the schedule, draw a node in
the precedence graph.
3. If Xi(A) and Yj(A) represent a conflict pair, then draw an edge from Ti to Tj for
each conflict pair. The precedence graph ensures that Ti gets executed before Tj.
4. The next step involves checking for any cycle formed in the graph. A schedule is a
conflict serializable if there is no cycle present.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 37

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).

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 38

TESTING OF SERIALIZABILITY
▪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.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 39

 Read(A): In T1, no subsequent writes to A, so no new edges
EXAMPLE 1 Read(B): In T2, no subsequent writes to B, so no new edges
Read(C): In T3, no subsequent writes to C, so no new edges
Write(B): B is subsequently read by T3, so add edge T2 → T3
Write(C): C is subsequently read by T1, so add edge T3 → T1
Write(A): A is subsequently read by T2, so add edge T1 → T2
Write(A): In T2, no subsequent reads to A, so no new edges
Write(C): In T1, no subsequent reads to C, so no new edges
Write(B): In T3, no subsequent reads to B, so no new edges

The precedence
T1 T2 graph for schedule
S1 contains a cycle
that's why Schedule
S1 is non-
serializable.
T3

Fig. 1 Precedence Graph for Schedule S1

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 40
 Read(A): In T4,no subsequent writes to A, so no new edges
Read(C): In T4, no subsequent writes to C, so no new edges
Write(A): A is subsequently read by T5, so add edge T4 → T5
EXAMPLE 2 Read(B): In T5,no subsequent writes to B, so no new edges
Write(C): C is subsequently read by T6, so add edge T4 → T6
Write(B): A is subsequently read by T6, so add edge T5 → T6
Write(C): In T6, no subsequent reads to C, so no new edges
Write(A): In T5, no subsequent reads to A, so no new edges
Write(B): In T6, no subsequent reads to B, so no new edges

The precedence
T4 T5 graph for schedule
S2 contains no cycle
that's why
ScheduleS2 is
serializable.
T6

Fig. 2 Precedence Graph for Schedule S2

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 41
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 Serializability is a procedure to check if the given schedule is consistent
or not. It is performed only if the given schedule is not conflict-serializable.
▪It is important to check the consistency of the schedule as an inconsistent
schedule leads to an inconsistent state of the program which is undesirable.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 42

WHAT IS VIEW SERIALIZABILITY?
▪A system handles multiple transactions running concurrently, there is a
possibility that a few of them leave the system databases in an inconsistent
state and thus, the system fails. To be aware of such schedules and save the
system from failures, we check if schedules are serializable or not. If the given
schedule is serializable implies it will never leave the database in an
inconsistent state.
▪Serial schedules are the schedules where no two transactions are executed
concurrently. Thus, serial schedules never leave the database in an inconsistent
state. If the given schedule is view serializable, then we are sure that it is a
consistent schedule or serial schedule.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 43

VIEW SERIALIZABILITY
▪View Serializability is a process used to check whether the given schedule is
view serializable or not.
▪To do so we check if the given schedule is View Equivalent to its serial
schedule.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 44

WHY DO WE NEED TO USE VIEW-
SERIALIZABILITY?
▪There is a possibility that even though the schedule does not conflict
serializable, it gives a consistent result.
▪This is because conflict serializability is limited to the precedence graph of a
schedule. If the precedence graph contains any loops/cycles, we cannot predict
whether a schedule is consistent or inconsistent.
▪To figure out the state of the schedule, we use the concept of View-
Serializability because we do not want to bind the concept of Serializability
only to Conflict with Serializability.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 45

 CONDITION FOR CONFLICT SERIALIZABLE

The cycle is present, so it is non conflict serializable. The cycle is not present, so it is conflict serializable.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 46

 PROBLEM-01:
Check whether the given schedule S is view serializable or not-

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 47

Solution-
We know, if a schedule is conflict serializable, then it is surely view serializable.
•So, let us check whether the given schedule is conflict serializable or not.
Checking Whether S is Conflict Serializable Or Not-
Step-01:
List all the conflicting operations and determine the dependency between the transactions-
▪W1(B) , W2(B) (T1 → T2)
▪W1(B) , W3(B) (T1 → T3)
▪W1(B) , W4(B) (T1 → T4)
▪W2(B) , W3(B) (T2 → T3)
▪W2(B) , W4(B) (T2 → T4)
▪W3(B) , W4(B) (T3 → T4)

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 48

Step-02:
Draw the precedence graph-

• Clearly, there exists no cycle in the precedence graph.

• Therefore, the given schedule S is conflict serializable.
• Thus, we conclude that the given schedule is also view
serializable.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 49

 PROBLEM-02:

▪Check whether the given schedule S is view serializable or not-

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 50

 Step-01:
List all the conflicting operations and determine the dependency
between the transactions-
•R1(A) , W3(A) (T1 → T3)
•R2(A) , W3(A) (T2 → T3)
•R2(A) , W1(A) (T2 → T1)
•W3(A) , W1(A) (T3 → T1)
Step-02:
•Clearly, there exists a cycle in the precedence graph.
Draw the precedence graph- •Therefore, the given schedule S is not conflict serializable.

Now,
•Since, the given schedule S is not conflict serializable, so, it may
or may not be view serializable.
•To check whether S is view serializable or not, let us use
another method.
29-Sep-24 •Let us BYcheck
COMPILED forTINSU,
MRS. JISHA blind
TCET writes. 51
▪Now,
•To check whether S is view serializable or not, let us use another method.
•Let us derive the dependencies and then draw a dependency graph.
▪Drawing a Dependency Graph-
•T1 firstly reads A and T3 firstly updates A.
•So, T1 must execute before T3.
•Thus, we get the dependency T1 → T3.
•Final updation on A is made by the transaction T1.
•So, T1 must execute after all other transactions.
•Thus, we get the dependency (T2, T3) → T1.
•There exists no write-read sequence.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 52

DEPENDENCY GRAPH

•Clearly, there exists a cycle in the dependency graph.

•Thus, we conclude that the given schedule S is not view
serializable.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 53

 PROBLEM-03:
▪Check whether the given schedule S is view serializable or not.
If yes, then give the serial schedule.
▪S : R1(A) , W2(A) , R3(A) , W1(A) , W3(A)

▪Solution-

▪For simplicity and better understanding, we can represent the

given schedule pictorially as-

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 54

•We know, if a schedule is conflict serializable, then it is surely view serializable.
•So, let us check whether the given schedule is conflict serializable or not.

▪Checking Whether S is Conflict Serializable Or Not-

▪ Step-01:
▪List all the conflicting operations and determine the dependency between the transactions-
•R1(A) , W2(A) (T1 → T2)
•R1(A) , W3(A) (T1 → T3)
•W2(A) , R3(A) (T2 → T3)
•W2(A) , W1(A) (T2 → T1)
•W2(A) , W3(A) (T2 → T3)
•R3(A) , W1(A) (T3 → T1)
•W1(A) , W3(A) (T1 → T3)

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 55

▪Step-02:
▪ Draw the precedence graph-
• Clearly, there exists a cycle in the precedence graph.
•Therefore, the given schedule S is not conflict serializable.
▪Now,
•Since, the given schedule S is not conflict serializable, so, it may or may not be view serializable.
•To check whether S is view serializable or not, let us use another method.
•Let us check for blind writes.
▪ Checking for Blind Writes-
▪ There exists a blind write W2 (A) in the given schedule S.
•Therefore, the given schedule S may or may not be view serializable.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 56

•To check whether S is view serializable or not, let us use another method.
•Let us derive the dependencies and then draw a dependency graph.
Drawing a Dependency Graph-
•T1 firstly reads A and T2 firstly updates A.
•So, T1 must execute before T2.
•Thus, we get the dependency T1 → T2.
•Final updating on A is made by the transaction T3. • Clearly, there exists no cycle in
•So, T3 must execute after all other transactions. the dependency graph.
• Therefore, the given schedule S
•Thus, we get the dependency (T1, T2) → T3. is view serializable.
• The serialization order T1 → T2
•From write-read sequence, we get the dependency T2 → T3 → T3.
▪ Now, let us draw a dependency graph using these dependencies-

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 57

 PROBLEM-05:

▪Check whether the given schedule S is

view serializable or not-

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 58

Solution-
▪We know, if a schedule is conflict serializable, then it is surely view serializable.
▪So, let us check whether the given schedule is conflict serializable or not.
▪Checking Whether S is Conflict Serializable Or Not-
▪Step-01:
List all the conflicting operations and determine the dependency between the
transactions-
▪R1(A) , W2(A) (T1 → T2)
▪R2(A) , W1(A) (T2 → T1)
▪W1(A) , W2(A) (T1 → T2)
▪R1(B) , W2(B) (T1 → T2)
▪R2(B) , W1(B) (T2 → T1)
29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 59
Step-02:
▪ Clearly, there exists a cycle in the precedence graph.
▪ Therefore, the given schedule S is not conflict serializable.
▪ Now since, the given schedule S is not conflict serializable, so, it may or may not be
view serializable.
▪ To check whether S is view serializable or not, let us use another method.
▪ Let us check for blind writes.

Checking for Blind Writes-

• There exists no blind write in the given schedule S.

• Therefore, it is surely not view serializable.

Alternatively,
•You could directly declare that the given schedule S is not view serializable.
•This is because there exists no blind write in the schedule.
•You
29-Sep-24need not check for conflict serializability.
COMPILED BY MRS. JISHA TINSU, TCET 60
SERIAL SCHEDULES VS SERIALIZABLE
SCHEDULES-

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 61

RECOVERY SYSTEM
▪Recoverability is a property of database systems that ensures that, in the
event of a failure or error, the system can recover the database to a consistent
state.
▪Recoverability guarantees that all committed transactions are durable and that
their effects are permanently stored in the database, while the effects of
uncommitted transactions are undone to maintain data consistency.
▪The recoverability property is enforced using transaction logs, which record all
changes made to the database during transaction processing.
▪When a failure occurs, the system uses the log to recover the database to a
consistent state, which involves either undoing the effects of uncommitted
transactions or redoing the effects of committed transactions.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 62

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.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 63

RECOVERABILITY OF SCHEDULE

Table 1

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 64

RECOVERABILITY OF SCHEDULE
▪The table 1 shows a schedule which has two transactions.
▪T1 reads and writes the value of A, and that value is read and
written by T2. T2 commits but later on, T1 fails. Due to the failure,
we have to rollback T1. T2 should also be rollback because it reads
the value written by T1 (Dirty Read), but T2 can't be rollback
because it already committed (Early commit). So, this type of
schedule is known as irrecoverable schedule.
▪Irrecoverable schedule: The schedule will be irrecoverable if Tj
reads the updated value of Ti and Tj committed before Ti commit.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 65

RECOVERABLE WITH CASCADING ROLLBACK

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 66

RECOVERABLE WITH CASCADING ROLLBACK:
▪The above table 2 shows a schedule with two transactions.
▪Transaction T1 reads and writes A, and that value is read and
written by transaction T2. But later on, T1 fails.
▪Due to this, we have to rollback T1. T2 should be rollback because
T2 has read the value written by T1. As it has not committed before
T1 commits so we can rollback transaction T2 as well. So, it is
recoverable with cascade rollback.
▪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.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 67

 CASCADE LESS RECOVERABLE ROLLBACK:

The above Table 3 shows a schedule with two transactions. Transaction T1 reads
and write A and commits, and that value is read and written by T2. So, this is a
cascade less recoverable schedule. But if T1 fails before commit, no other
transaction has read its value, so there is no need to rollback other transaction.
29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 68
 STRICT SCHEDULE
▪A schedule is strict if it is both recoverable and
cascades.
▪In a strict schedule, a transaction that has read
uncommitted data from another transaction cannot
commit before that transaction commits, and a
transaction that has updated the database must
commit before any other transaction reads or writes
the same data.
▪If a transaction fails before committing, its updates
must be rolled back, and any transactions that have
read its uncommitted data must also be rolled back.
29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 69
RECOVERY FROM TRANSACTION FAILURES
▪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.
▪Types of Recovery Techniques in DBMS:
▪Rollback/Undo Recovery Technique
▪Commit/Redo Recovery Technique
▪Checkpoint Recovery Technique

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 70

LOG BASED RECOVERY IN DBMS
▪The atomicity property of a DBMS ensures that either all
operations of a transaction are completed, or none are
executed.
▪Changes made by an aborted transaction must not be
visible in the database, while changes from a committed
transaction must be reflected.
▪To achieve atomicity, the system first stores information
about the modifications in stable storage before altering
the database.
▪This helps guarantee that all committed transaction
changes are applied to the database, and any changes
made by an aborted transaction are discarded.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 71

LOG AND LOG RECORDS
▪The log is a sequence of log records, recording all the updated activities in the
database. In stable storage, logs for each transaction are maintained.
▪Any operation which is performed on the database is recorded on the log. Prior to
performing any modification to the database, an updated log record is created to
reflect that modification.
▪An update log record represented as: <Ti, Xj, V1, V2> has these fields:
1. Transaction identifier: Unique Identifier of the transaction that performed the write
operation.
2. Data item: Unique identifier of the data item written.
3. Old value: Value of data item prior to write.
4. New value: Value of data item after write operation.
29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 72
LOG AND LOG RECORDS
1. <Ti start> …………………………..Transaction Ti starts.

2. <Ti, Xj, V1, V2> .................... Transaction Ti has performed a write on data item Xj.
Xj has a value V1 before write & will have value V2 after write

3. <Ti commit>………………………………when a transaction Ti has committed.

4. <Ti abort>…………………………………. transaction Ti is aborted.

Example: <T12, 13, 1000, 900>

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 73

ROLLBACK/UNDO RECOVERY TECHNIQUE
▪The 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.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 74

COMMIT/REDO RECOVERY TECHNIQUE
▪The 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 consistent state.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 75

CHECKPOINT RECOVERY TECHNIQUE
▪Checkpoint Recovery is a technique used to improve data integrity and
system stability, especially in databases and distributed systems.
▪It entails preserving the system’s state at regular intervals, known as
checkpoints, at which all ongoing transactions are either completed or not
initiated.
▪This saved state, which includes memory and CPU registers, is kept in stable,
non-volatile storage so that it can withstand system crashes.
▪In the event of a breakdown, the system can be restored to the most recent
checkpoint, which reduces data loss and downtime.
▪The frequency of checkpoint formation is carefully regulated to decrease
system overhead while ensuring that recent data may be restored quickly.
29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 76
RECOVERY PROCESS WITH CHECKPOINTS
▪When a failure occurs, the recovery process proceeds as follows:
1.Find the Latest Checkpoint:
1. The system reads the log backward to find the most recent checkpoint.
2. From the checkpoint record, the system retrieves the list of active transactions
at the time of the checkpoint.
2.Redo Phase:
1. The system scans the log forward from the checkpoint to the end of the log,
redoing all operations from committed transactions to ensure all committed
changes are reflected in the database.
3.Undo Phase:
1. The system undoes any changes made by uncommitted transactions that were
active at the time of the failure. These transactions are rolled back to maintain
consistency.
29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 77
DEADLOCK IN DBMS
▪In database management systems (DBMS) a deadlock occurs when two or
more transactions are unable to the proceed because each transaction is
waiting for the other to the release locks on resources.
▪This situation creates a cycle of the dependencies where no transaction can
continue leading to the standstill in the system.
▪ Impacts - performance and reliability of a DBMS

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 78

CHARACTERISTICS OF DEADLOCK
▪Mutual Exclusion: Only one transaction can hold a particular resource at a
time.
▪Hold and Wait: The Transactions holding resources may request additional
resources held by others.
▪No Preemption: The Resources cannot be forcibly taken from the transaction
holding them.
▪Circular Wait: A cycle of transactions exists where each transaction is waiting
for the resource held by the next transaction in the cycle.

29-Sep-24 COMPILED BY MRS. JISHA TINSU, TCET 79