Unit No.

3 Transaction and Concurrency control

Unit No.3. Transaction and Concurrency control

3.1. Concept of transaction, ACID properties, States of transaction

3.2. Concurrency control, Problems in concurrency controls

3.3. Scheduling of transactions, Serializability and testing of serilaizibility

3.4. Lock-based Protocol and Time stamp-based ordering protocols

3.5. Deadlock Handling

3.1. Concept of transaction, ACID properties, States of transaction
Transaction
A transaction can be defined as a group of tasks. A single task is the minimum processing unit which cannot be divided
further.
Let’s take an example of a simple transaction. Suppose a bank employee transfers Rs. 500 from A's account to B's account.
This very simple and small transaction involves several low-level tasks.
A’s Account

Open_Account(A)
Old_Balance = A.balance
New_Balance = Old_Balance – 500
A.balance = New_Balance
Close_Account(A)
B’s Account
Open_Account(B)
Old_Balance = B.balance
New_Balance = Old_Balance + 500
B.balance = New_Balance

Close_Account(B)
ACID Properties :-
A transaction is a very small unit of a program and it may contain several lowlevel tasks. A transaction in a database system
must maintain Atomicity, Consistency, Isolation, and Durability − commonly known as ACID properties − in order to ensure
accuracy, completeness, and data integrity.

•Atomicity − This property states that a transaction must be treated as an atomic unit, that is, either all of its operations are
executed or none. There must be no state in a database where a transaction is left partially completed. States should be
defined either before the execution of the transaction or after the execution/abortion/failure of the transaction.

•Consistency − The database must remain in a consistent state after any transaction. No transaction should have any
adverse effect on the data residing in the database. If the database was in a consistent state before the execution of a
transaction, it must remain consistent after the execution of the transaction as well.
•Durability − The database should be durable enough to hold all its latest updates even if the system fails or restarts. If a
transaction updates a chunk of data in a database and commits, then the database will hold the modified data. If a
transaction commits but the system fails before the data could be written on to the disk, then that data will be updated
once the system springs back into action.

•Isolation − In a database system where more than one transaction are being executed simultaneously and in parallel, the
property of isolation states that all the transactions will be carried out and executed as if it is the only transaction in the
system. No transaction will affect the existence of any other transaction.
States of transaction / Transaction states in DBMS :-
In a database, the transaction can be in one of the following states -
Active state
•The active state is the first state of every transaction. In this state, the transaction is being executed.
•For example: Insertion or deletion or updating a record is done here. But all the records are still not saved to the
database.

Partially committed
•In the partially committed state, a transaction executes its final operation, but the data is still not saved to the database.
•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.
Failed state
If any of the checks made by the database recovery system fails, then the transaction is said to be in the failed state.
In the example of total mark calculation, if the database is not able to fire a query to fetch the marks, then the transaction
will fail to execute.

Aborted
•If 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.
•After aborting the transaction, the database recovery module will select one of the two operations:
1. Re-start the transaction
2. Kill the transaction
3.3. Scheduling of transactions, Serializability and testing of serilaizibility

A series of operation from one transaction to another transaction is known as schedule. It is used to preserve the order of
the operation in each of the individual transaction.
1. Serial Schedule
The serial schedule is a type of schedule where one transaction is executed completely before starting another transaction.
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 T2 which was followed by all the operations of T1.
•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.
2. 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.
3. 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.
Serializability

A schedule is serialized if it is equivalent to a serial schedule. A concurrent schedule must ensure it is the same as if
executed serially means one after another. It refers to the sequence of actions such as read, write, abort, commit are
performed in a serial manner.
Serializability is a term that is a property of the system that describes how the different process operates the shared data.
If the result given by the system is similar to the operation performed by the system, then in this situation, we call that
system serializable. Here the cooperation of the system means there is no overlapping in the execution of the data. In
DBMS, when the data is being written or read then, the DBMS can stop all the other processes from accessing the data.
Types of serializability
There are two types of serializability −
1. View serializability
A schedule is view-serializability if it is viewed equivalent to a serial schedule.
The rules it follows are as follows −
•T1 is reading the initial value of A, then T2 also reads the initial value of A.
•T1 is the reading value written by T2, then T2 also reads the value written by T1.
•T1 is writing the final value, and then T2 also has the write operation as the final value.
2. Conflict serializability
It orders any conflicting operations in the same way as some serial execution. A pair of operations is said to conflict if th ey
operate on the same data item and one of them is a write operation.
That means
•Readi(x) readj(x) - non conflict read-read operation
•Readi(x) writej(x) - conflict read-write operation.
•Writei(x) readj(x) - conflict write-read operation.
•Writei(x) writej(x) - conflict write-write operation.
Testing of Serilaizibility

Serializability is a type of property of DBMS in which each transaction is executed independently and automatically, even
though these transactions are executed concurrently. In other words, we can say that if there are several transactions
executed concurrently, then the main work of the serializability function is to arrange these several transactions in a
sequential manner.
For better understanding, let's explain these with an example. Suppose there are two users Sona and Archita. Each executes
two transactions. Let's transactions T1 and T2 are executed by Sona, and T3 and T4 are executed by Archita. Suppose
transaction T1 reads and writes the data item A, transaction T2 reads the data item B, transaction T3 reads and writes the
data item C and transaction T4 reads the data item D. Lets the schedule the above transaction as below.

•
T1: Read A → Write A→ Read B → Write B`
•
`T2: Read B → Write B`
•
`T3: Read C → Write C→ Read D → Write D`
• `T4: Read D → Write D
3.4. Lock-based Protocol and Time stamp-based ordering protocols

1. Lock-based Protocols :-
Database systems equipped with lock-based protocols use a mechanism by which any transaction cannot read or write
data until it acquires an appropriate lock on it. Locks are of two kinds −

•Binary Locks − A lock on a data item can be in two states; it is either locked or unlocked.

•Shared/exclusive − This type of locking mechanism differentiates the locks based on their uses. If a lock is acquired on a
data item to perform a write operation, it is an exclusive lock. Allowing more than one transaction to write on the same
data item would lead the database into an inconsistent state. Read locks are shared because no data value is being
changed.
There are four types of lock protocols available −
1. Simplistic Lock Protocol
It is the simplest way of locking the data while transaction. Simplistic lock-based protocols allow all the transactions to get
the lock on the data before insert or delete or update on it.
• It will unlock the data item after completing t Simplistic lock-based protocols allow transactions to obtain a lock on every
object before a 'write' operation is performed. Transactions may unlock the data item after completing the ‘write’
operation.
2. Pre-claiming Lock Protocol
Pre-claiming protocols evaluate their operations and create a list of data items on which they need locks. Before initiating
an execution, the transaction requests the system for all the locks it needs beforehand. If all the locks are granted, the
transaction executes and releases all the locks when all its operations are over. If all the locks are not granted, the
transaction rolls back and waits until all the locks are granted.
3. Two-Phase Locking 2PL
This locking protocol divides the execution phase of a transaction into three parts. In the first part, when the transaction
starts executing, it seeks permission for the locks it requires. The second part is where the transaction acquires all the
locks. As soon as the transaction releases its first lock, the third phase starts. In this phase, the transaction cannot demand
any new locks; it only releases the acquired locks.

Two-phase locking has two phases, one is growing, where all the locks are being acquired by the transaction; and the
second phase is shrinking, where the locks held by the transaction are being released.
4. Strict Two-Phase Locking
The first phase of Strict-2PL is same as 2PL. After acquiring all the locks in the first phase, the transaction continues to
execute normally. But in contrast to 2PL, Strict-2PL does not release a lock after using it. Strict-2PL holds all the locks until
the commit point and releases all the locks at a time.
2. Time stamp-based ordering protocols
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.

• Let's assume there are two transactions T1 and T2. Suppose the transaction T1 has entered the system at 007
times and transaction T2 has entered the system at 009 times. T1 has the higher priority, so it executes first as it
is entered the system first.
• The timestamp ordering protocol also maintains the timestamp of last 'read' and 'write' operation on a data
3.5. Deadlock Handling

Deadlock :-
In a database management system (DBMS), a deadlock occurs when two or more transactions are waiting for each other
to release resources, such as locks on database objects, that they need to complete their operations. As a result, none of
the transactions can proceed, leading to a situation where they are stuck or “deadlocked.”

Deadlocks can happen in multi-user environments when two or more transactions are running concurrently and try to
access the same data in a different order. When this happens, one transaction may hold a lock on a resource that
another transaction needs, while the second transaction may hold a lock on a resource that the first transaction needs.
Both transactions are then blocked, waiting for the other to release the resource they need. DBMSs often use various
techniques to detect and resolve deadlocks automatically.
For example: In the student table, transaction T1 holds a lock on some rows and needs to update some rows in the grade
table. Simultaneously, transaction T2 holds locks on some rows in the grade table and needs to update the rows in the
Student table held by Transaction T1.
Now, the main problem arises. Now Transaction T1 is waiting for T2 to release its lock and similarly, transaction T2 is waiting
for T1 to release its lock. All activities come to a halt state and remain at a standstill. It will remain in a standstill until the
DBMS detects the deadlock and aborts one of the transactions.
Deadlock Handling in Centralized Systems
There are three classical approaches for deadlock handling, namely −
Deadlock prevention.
Deadlock avoidance.
Deadlock detection and removal.
Deadlock Avoidance
•When a database is stuck in a deadlock state, then it is better to avoid the database rather than aborting or restating the
database. This is a waste of time and resource.
•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. For the larger database,
deadlock prevention method can be used.

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.
Wait for Graph
•This is the suitable method for deadlock detection. In this method, a graph is created based on the transaction and their
lock. If the created graph has a cycle or closed loop, then there is a deadlock.
•The wait for the graph is maintained by the system for every transaction which is waiting for some data held by the others.
The system keeps checking the graph if there is any cycle in the graph.
The wait for a graph for the above scenario is shown below:

Deadlock Prevention
•Deadlock prevention method is suitable for a large database. If the resources are allocated in such a way that deadlock
never occurs, then the deadlock can be prevented.
•The Database management system analyzes the operations of the transaction whether they can create a deadlock
situation or not. If they do, then the DBMS never allowed that transaction to be executed.