0% found this document useful (0 votes)
17 views14 pages

DBMS 15

The document provides an overview of transactions in database systems, defining a transaction as a set of logically related operations. It discusses the operations involved in transactions, their various states, and the ACID properties that ensure database consistency. Additionally, it addresses concurrency problems and techniques for managing simultaneous transactions to maintain data integrity.

Uploaded by

tapatapdobo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views14 pages

DBMS 15

The document provides an overview of transactions in database systems, defining a transaction as a set of logically related operations. It discusses the operations involved in transactions, their various states, and the ACID properties that ensure database consistency. Additionally, it addresses concurrency problems and techniques for managing simultaneous transactions to maintain data integrity.

Uploaded by

tapatapdobo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 14

Government of West Bengal

Dr. Meghnad Saha Institute of Technology, Haldia


Department of Computer Science & Technology
Class Notes on Transaction

“Transaction is a set of operations which are all logically related.”


OR
“Transaction is a single logical unit of work formed by a set of operations.”

Example: Suppose an employee of bank transfers Rs 800 from X's account to Y's account.
This small transaction contains several low-level tasks:
X's Account
1. Open_Account(X)
2. Old_Balance = X.balance
3. New_Balance = Old_Balance - 800
4. X.balance = New_Balance
5. Close_Account(X)

Y's Account
1. Open_Account(Y)
2. Old_Balance = Y.balance
3. New_Balance = Old_Balance + 800
4. Y.balance = New_Balance
5. Close_Account(Y)

Operations in Transaction-
The main operations in a transaction are-
1. Read Operation
2. Write Operation
1. Read Operation-
 Read operation reads the data from the database and then stores it in the buffer in
main memory.

 For example- Read(A) instruction will read the value of A from the database and will
store it in the buffer in main memory.

2. Write Operation-
 Write operation writes the updated data value back to the database from the buffer.
 For example- Write(A) will write the updated value of A from the buffer to the
database.
Let's take an example to debit transaction from an account which consists of following
operations:
1. R(X);
2. X = X - 500;

Prepared by Sukanta Singh, Lecturer in CST Page 1 of 1


Government of West Bengal
Dr. Meghnad Saha Institute of Technology, Haldia
Department of Computer Science & Technology
Class Notes on Transaction

3. W(X);
Let's assume the value of X before starting of the transaction is 4000.
 The first operation reads X's value from database and stores it in a buffer.
 The second operation will decrease the value of X by 500. So buffer will contain 3500.
 The third operation will write the buffer's value to the database. So X's final value will
be 3500.
But it may be possible that because of the failure of hardware, software or power, etc. that
transaction may fail before finished all the operations in the set.
For example: If in the above transaction, the debit transaction fails after executing
operation 2 then X's value will remain 4000 in the database which is not acceptable by the
bank.
To solve this problem, we have two important operations:
Commit: It is used to save the work done permanently.
Rollback: It is used to undo the work done.

Transaction States-

A transaction goes through many different states throughout its life cycle.
These states are called as transaction states.
Transaction states are as follows-
1. Active state
2. Partially committed state
3. Committed state
4. Failed state
5. Aborted state
6. Terminated state

Prepared by Sukanta Singh, Lecturer in CST Page 2 of 1


Government of West Bengal
Dr. Meghnad Saha Institute of Technology, Haldia
Department of Computer Science & Technology
Class Notes on Transaction

1. Active State-
 This is the first state in the life cycle of a transaction.
 A transaction is called in an active state as long as its instructions are getting
executed.
 All the changes made by the transaction now are stored in the buffer in main
memory.

2. Partially Committed State-


 After the last instruction of transaction has executed, it enters into a partially
committed state.
 After entering this state, the transaction is considered to be partially committed.
 It is not considered fully committed because all the changes made by the transaction
are still stored in the buffer in main memory.

3. Committed State-
 After all the changes made by the transaction have been successfully stored into the
database, it enters into a committed state.
 Now, the transaction is considered to be fully committed.

NOTE-
 After a transaction has entered the committed state, it is not possible to roll back the
transaction.
 In other words, it is not possible to undo the change that has been made by the
transaction.

Prepared by Sukanta Singh, Lecturer in CST Page 3 of 1


Government of West Bengal
Dr. Meghnad Saha Institute of Technology, Haldia
Department of Computer Science & Technology
Class Notes on Transaction

 This is because the system is updated into a new consistent state.


 The only way to undo the changes is by carrying out another transaction called
as compensating transaction that performs the reverse operations.

4. Failed State-
 When a transaction is getting executed in the active state or partially committed state
and some failure occurs due to which it becomes impossible to continue the
execution, it enters into a failed state.

5. Aborted State-
 After the transaction has failed and entered into a failed state, all the changes made
by it have to be undone.
 To undo the changes made by the transaction, it becomes necessary to roll back the
transaction.
 After the transaction has rolled back completely, it enters into an aborted state.

6. Terminated State-
 This is the last state in the life cycle of a transaction.
 After entering the committed state or aborted state, the transaction finally enters into
a terminated state where its life cycle finally comes to an end.

ACID Properties-
 It is important to ensure that the database remains consistent before and after the
transaction.
 To ensure the consistency of database, certain properties are followed by all the
transactions occurring in the system.
 These properties are called as ACID Properties of a transaction.

1. Atomicity-
 This property ensures that either the transaction occurs completely or it does not
occur at all.

Prepared by Sukanta Singh, Lecturer in CST Page 4 of 1


Government of West Bengal
Dr. Meghnad Saha Institute of Technology, Haldia
Department of Computer Science & Technology
Class Notes on Transaction

 In other words, it ensures that no transaction occurs partially.


 That is why, it is also referred to as “All or nothing rule“.
 It is the responsibility of Transaction Control Manager to ensure atomicity of the
transactions.

Example: Let's assume that following transaction T consisting of T1 and T2. A consists of
Rs 600 and B consists of Rs 300. Transfer Rs 100 from account A to account B.

T1 T2

Read(A) Read(B)
A:= A-100 Y:= Y+100
Write(A) Write(B)

After completion of the transaction, A consists of Rs 500 and B consists of Rs 400.

If the transaction T fails after the completion of transaction T1 but before completion of
transaction T2, then the amount will be deducted from A but not added to B. This shows
the inconsistent database state. In order to ensure correctness of database state, the
transaction must be executed in entirety.

2. Consistency-
 This property ensures that integrity constraints are maintained.
 In other words, it ensures that the database remains consistent before and after the
transaction.
 It is the responsibility of DBMS and application programmer to ensure consistency of
the database.

For example: The total amount must be maintained before or after the transaction.
1. Total before T occurs = 600+300=900
2. Total after T occurs= 500+400=900
Therefore, the database is consistent. In the case when T1 is completed but T2 fails, then
inconsistency will occur.
3. Isolation-
 This property ensures that multiple transactions can occur simultaneously without
causing any inconsistency.
 During execution, each transaction feels as if it is getting executed alone in the
system.
 A transaction does not realize that there are other transactions as well getting
executed parallel.

Prepared by Sukanta Singh, Lecturer in CST Page 5 of 1


Government of West Bengal
Dr. Meghnad Saha Institute of Technology, Haldia
Department of Computer Science & Technology
Class Notes on Transaction

 A change made by a transaction becomes visible to other transactions only after they
are written in the memory.
 The resultant state of the system after executing all the transactions is same as the
state that would be achieved if the transactions were executed serially one after the
other.
 It is the responsibility of concurrency control manager to ensure isolation for all the
transactions.

4. Durability-
 This property ensures that all the changes made by a transaction after its successful
execution is written successfully to the disk.
 It also ensures that these changes exist permanently and are never lost even if there
occurs a failure of any kind.
 It is the responsibility of recovery manager to ensure durability in the database.

Concurrency Problems in DBMS-


 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-

Prepared by Sukanta Singh, Lecturer in CST Page 6 of 1


Government of West Bengal
Dr. Meghnad Saha Institute of Technology, Haldia
Department of Computer Science & Technology
Class Notes on Transaction

1. Dirty Read Problem-

Reading the data written by an uncommitted transaction is called as dirty read.

This read is called as dirty read because-


 There is always a chance that the uncommitted transaction might roll back later.
 Thus, uncommitted transaction might make other transactions read a value that
does not even exist.
 This leads to inconsistency of the database.

NOTE-
 Dirty read does not lead to inconsistency always.
 It becomes problematic only when the uncommitted transactions fails and roll backs
later due to some reason.

Example-

Here,
1. T1 reads the value of A.
2. T1 updates the value of A in the buffer.
3. T2 reads the value of A from the buffer.
4. T2 writes the updated the value of A.
5. T2 commits.
6. T1 fails in later stages and rolls back.

Prepared by Sukanta Singh, Lecturer in CST Page 7 of 1


Government of West Bengal
Dr. Meghnad Saha Institute of Technology, Haldia
Department of Computer Science & Technology
Class Notes on Transaction

In this example,
 T2 reads the dirty value of A written by the uncommitted transaction T1.
 T1 fails in later stages and roll backs.
 Thus, the value that T2 read now stands to be incorrect.
 Therefore, database becomes inconsistent.

2. Unrepeatable Read Problem-


This problem occurs when a transaction gets to read unrepeated i.e. different values of the
same variable in its different read operations even when it has not updated its value.
Example-

Here,
1. T1 reads the value of X (= 10 say).
2. T2 reads the value of X (= 10).
3. T1 updates the value of X (from 10 to 15 say) in the buffer.
4. T2 again reads the value of X (but = 15).

In this example,
 T2 gets to read a different value of X in its second reading.
 T2 wonders how the value of X got changed because according to it, it is running in
isolation.

Prepared by Sukanta Singh, Lecturer in CST Page 8 of 1


Government of West Bengal
Dr. Meghnad Saha Institute of Technology, Haldia
Department of Computer Science & Technology
Class Notes on Transaction

3. Lost Update Problem-

This problem occurs when multiple transactions execute concurrently and updates from
one or more transactions get lost.
Example-

Here,
1. T1 reads the value of A (= 10 say).
2. T2 updates the value to A (= 15 say) in the buffer.
3. T2 does blind write A = 25 (write without read) in the buffer.
4. T2 commits.
5. When T1 commits, it writes A = 25 in the database.

In this example,
 T1 writes the over written value of X in the database.
 Thus, update from T1 gets lost.

NOTE-
 This problem occurs whenever there is a write-write conflict.
 In write-write conflict, there are two writes one by each transaction on the same data
item without any read in the middle.

Prepared by Sukanta Singh, Lecturer in CST Page 9 of 1


Government of West Bengal
Dr. Meghnad Saha Institute of Technology, Haldia
Department of Computer Science & Technology
Class Notes on Transaction

4. Phantom Read Problem-

This problem occurs when a transaction reads some variable from the buffer and when it
reads the same variable later; it finds that the variable does not exist.
Example-

Here,
1. T1 reads X.
2. T2 reads X.
3. T1 deletes X.
4. T2 tries reading X but does not find it.

In this example,
 T2 finds that there does not exist any variable X when it tries reading X again.
 T2 wonders who deleted the variable X because according to it, it is running in
isolation.

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.

Prepared by Sukanta Singh, Lecturer in CST Page 10 of 1


Government of West Bengal
Dr. Meghnad Saha Institute of Technology, Haldia
Department of Computer Science & Technology
Class Notes on Transaction

Schedules and Conflicts


In a system with a number of simultaneous transactions, a schedule is the total order of
execution of operations. Given a schedule S comprising of n transactions, say T1, T2,
T3………..Tn; for any transaction Ti, the operations in Ti must execute as laid down in the
schedule S.
Types of Schedules
There are two types of schedules −
Serial Schedules − In a serial schedule, at any point of time, only one transaction is active,
i.e. there is no overlapping of transactions. This is depicted in the following graph −

Parallel Schedules − In parallel schedules, more than one transactions are active
simultaneously, i.e. the transactions contain operations that overlap at time. This is
depicted in the following graph −

Conflicts in Schedules
In a schedule comprising of multiple transactions, a conflict occurs when two active
transactions perform non-compatible operations. Two operations are said to be in conflict,
when all of the following three conditions exists simultaneously −
The two operations are parts of different transactions.
 Both the operations access the same data item.

Prepared by Sukanta Singh, Lecturer in CST Page 11 of 1


Government of West Bengal
Dr. Meghnad Saha Institute of Technology, Haldia
Department of Computer Science & Technology
Class Notes on Transaction

 At least one of the operations is a write_item() operation, i.e. it tries to modify the
data item.
Serializability
A serializable schedule of ‘n’ transactions is a parallel schedule which is equivalent to a
serial schedule comprising of the same ‘n’ transactions. A serializable schedule contains the
correctness of serial schedule while ascertaining better CPU utilization of parallel schedule.
Equivalence of Schedules
Equivalence of two schedules can be of the following types −
Result equivalence − Two schedules producing identical results are said to be result
equivalent.
View equivalence − Two schedules that perform similar action in a similar manner are
said to be view equivalent.
Conflict equivalence − Two schedules are said to be conflict equivalent if both contain the
same set of transactions and has the same order of conflicting pairs of operations.
Controlling Concurrency
Concurrency controlling techniques ensure that multiple transactions are executed
simultaneously while maintaining the ACID properties of the transactions and
serializability in the schedules.
In this section, we will study the various approaches for concurrency control.
Locking Based Concurrency Control Protocols
Locking-based concurrency control protocols use the concept of locking data items.
A lock is a variable associated with a data item that determines whether read/write
operations can be performed on that data item. Generally, a lock compatibility matrix is
used which states whether a data item can be locked by two transactions at the same time.
Locking-based concurrency control systems can use either one-phase or two-phase locking
protocols.
One-phase Locking Protocol
In this method, each transaction locks an item before use and releases the lock as soon as
it has finished using it. This locking method provides for maximum concurrency but does
not always enforce serializability.
Two-phase Locking Protocol
In this method, all locking operations precede the first lock-release or unlock operation. The
transaction comprise of two phases. In the first phase, a transaction only acquires all the
locks it needs and do not release any lock. This is called the expanding or the growing
phase. In the second phase, the transaction releases the locks and cannot request any new
locks. This is called the shrinking phase.

Prepared by Sukanta Singh, Lecturer in CST Page 12 of 1


Government of West Bengal
Dr. Meghnad Saha Institute of Technology, Haldia
Department of Computer Science & Technology
Class Notes on Transaction

Every transaction that follows two-phase locking protocol is guaranteed to be serializable.


However, this approach provides low parallelism between two conflicting transactions.
Timestamp Concurrency Control Algorithms
Timestamp-based concurrency control algorithms use a transaction’s timestamp to
coordinate concurrent access to a data item to ensure serializability. A timestamp is a
unique identifier given by DBMS to a transaction that represents the transaction’s start
time.
These algorithms ensure that transactions commit in the order dictated by their
timestamps. An older transaction should commit before a younger transaction, since the
older transaction enters the system before the younger one.
Timestamp-based concurrency control techniques generate serializable schedules such that
the equivalent serial schedule is arranged in order of the age of the participating
transactions.
Some of timestamp based concurrency control algorithms are −
Basic timestamp ordering algorithm.
Conservative timestamp ordering algorithm.
Multiversion algorithm based upon timestamp ordering.
Timestamp based ordering follow three rules to enforce serializability −
Access Rule − When two transactions try to access the same data item simultaneously, for
conflicting operations, priority is given to the older transaction. This causes the younger
transaction to wait for the older transaction to commit first.
Late Transaction Rule − If a younger transaction has written a data item, then an older
transaction is not allowed to read or write that data item. This rule prevents the older
transaction from committing after the younger transaction has already committed.
Younger Transaction Rule − A younger transaction can read or write a data item that has
already been written by an older transaction.
Optimistic Concurrency Control Algorithm
In systems with low conflict rates, the task of validating every transaction for serializability
may lower performance. In these cases, the test for serializability is postponed to just before
commit. Since the conflict rate is low, the probability of aborting transactions which are not
serializable is also low. This approach is called optimistic concurrency control technique.
In this approach, a transaction’s life cycle is divided into the following three phases −
Execution Phase − A transaction fetches data items to memory and performs operations
upon them.
Validation Phase − A transaction performs checks to ensure that committing its changes
to the database passes serializability test.
Commit Phase − A transaction writes back modified data item in memory to the disk.

Prepared by Sukanta Singh, Lecturer in CST Page 13 of 1


Government of West Bengal
Dr. Meghnad Saha Institute of Technology, Haldia
Department of Computer Science & Technology
Class Notes on Transaction

This algorithm uses three rules to enforce serializability in validation phase −


Rule 1 − Given two transactions Ti and Tj, if Ti is reading the data item which Tj is writing,
then Ti’s execution phase cannot overlap with Tj’s commit phase. Tj can commit only after
Ti has finished execution.
Rule 2 − Given two transactions Ti and Tj, if Ti is writing the data item that Tj is reading,
then Ti’s commit phase cannot overlap with Tj’s execution phase. Tj can start executing only
after Ti has already committed.
Rule 3 − Given two transactions Ti and Tj, if Ti is writing the data item which Tj is also
writing, then Ti’s commit phase cannot overlap with Tj’s commit phase. Tj can start to
commit only after Ti has already committed.

Prepared by Sukanta Singh, Lecturer in CST Page 14 of 1

You might also like