Transaction

o The transaction is a set of logically related operation. It contains a group of

tasks.
o A transaction is an action or series of actions. It is performed by a single user
to perform operations for accessing the contents of the database.

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 of Transaction:
Following are the main operations of transaction:

46.7K
All the Apps That Support Dynamic Island on iPhone 14 Pro

Read(X): Read operation is used to read the value of X from the database and stores
it in a buffer in main memory.

Write(X): Write operation is used to write the value back to the database from the
buffer.
Let's take an example to debit transaction from an account which consists of
following operations:

1. 1. R(X);
2. 2. X = X - 500;
3. 3. W(X);

Let's assume the value of X before starting of the transaction is 4000.

o The first operation reads X's value from database and stores it in a buffer.
o The second operation will decrease the value of X by 500. So buffer will
contain 3500.
o 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.

States of Transaction
In a database, the transaction can be in one of the following states -

Active state
o The active state is the first state of every transaction. In this state, the transaction is
being executed.
o 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
o In the partially committed state, a transaction executes its final operation, but the
data is still not saved to the database.
o 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
o If any of the checks made by the database recovery system fails, then the transaction
is said to be in the failed state.
o 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
o 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.
o 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.
o After aborting the transaction, the database recovery module will select one of the
two operations:
1. Re-start the transaction
2. Kill the transaction

ACID Properties in DBMS

DBMS is the management of data that should remain integrated when any changes
are done in it. It is because if the integrity of the data is affected, whole data will get
disturbed and corrupted. Therefore, to maintain the integrity of the data, there are
four properties described in the database management system, which are known as
the ACID properties. The ACID properties are meant for the transaction that goes
through a different group of tasks, and there we come to see the role of the ACID
properties.

In this section, we will learn and understand about the ACID properties. We will learn
what these properties stand for and what does each property is used for. We will also
understand the ACID properties with the help of some examples.
ACID Properties
The expansion of the term ACID defines for:

1) 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. In the case of executing operations on the transaction,
the operation should be completely executed and not partially.

Example: If Remo has account A having $30 in his account from which he wishes to
send $10 to Sheero's account, which is B.

In account B, a sum of $ 100 is already present.

When $10 will be transferred to account B, the sum will become $110.

Now, there will be two operations that will take place.

One is the amount of $10 that Remo wants to transfer will be debited from his
account A, and the same amount will get credited to account B, i.e., into Sheero's
account.

Now, what happens - the first operation of debit executes successfully, but the credit
operation, however, fails.

Thus, in Remo's account A, the value becomes $20, and to that of Sheero's account, it
remains $100 as it was previously present.

In the above diagram, it can be seen that after crediting $10, the amount is still $100
in account B. So, it is not an atomic transaction.

The below image shows that both debit and credit operations are done successfully.
Thus the transaction is atomic.
Thus, when the amount loses atomicity, then in the bank systems, this becomes a
huge issue, and so the atomicity is the main focus in the bank systems.

2) Consistency
The word consistency means that the value should remain preserved always.

The integrity of the data should be maintained, which means if a change in the database is
made, it should remain preserved always. In the case of transactions, the integrity of the data
is very essential so that the database remains consistent before and after the transaction. The
data should always be correct.

Example:
In the above figure, there are three accounts, A, B, and C, where A is making a
transaction T one by one to both B & C. There are two operations that take place, i.e.,
Debit and Cre dit. Account A firstly debits $50 to account B, and the amount in
account A is read $300 by B before the transaction. After the successful transaction T,
the available amount in B becomes $150. Now, A debits $20 to account C, and that
time, the value read by C is $250 (that is correct as a debit of $50 has been
successfully done to B). The debit and credit operation from account A to C has been
done successfully. We can see that the transaction is done successfully, and the value
is also read correctly. Thus, the data is consistent. In case the value read by B and C is
$300, which means that data is inconsistent because when the debit operation
executes, it will not be consistent.

3) 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. Any changes that occur in any particular transaction will
not be seen by other transactions until the change is not committed in the memory.

Example: If two operations are concurrently running on two different accounts, then
the value of both accounts should not get affected. The value should remain
persistent. As you can see in the below diagram, account A is making T1 and T2
transactions to account B and C, but both are executing independently without
affecting each other. It is known as Isolation.

4) Durability
Durability ensures the permanency of something. In DBMS, the term durability
ensures that the data after the successful execution of the operation becomes
permanent in the database. The durability of the data should be so perfect that even
if the system fails or leads to a crash, the database still survives. However, if gets lost,
it becomes the responsibility of the recovery manager for ensuring the durability of
the database. For committing the values, the COMMIT command must be used every
time we make changes.

Therefore, the ACID property of DBMS plays a vital role in maintaining the
consistency and availability of data in the database.
Thus, it was a precise introduction of ACID properties in DBMS. We have discussed
these properties in the transaction section also.

Implementation of atomicity and durability:

The recovery-management component of a database system implements the support for

atomicity and durability.

The shadow-database scheme that have a only one transaction is active at a time and data
base is simply a file on the disk. A pointer called db_pointer said points to

the current consistent copy of the database. All updates are made on a shadow copy of the
database, and db_pointer is made to point to the updated shadow copy only after the
transaction reaches partial commit and all the updated pages have been flushed to disk.

In case transaction fails, old consistent copy pointed to by db_pointer can be used, and the
shadow copy can be deleted. Transaction said to be committed at the point where the
updated. Db-pointer is written to the disk. If transaction fails at any time before the db –
pointer is updated , the old content of the data base are not affected

We can abort the transaction by just deleting the new copy of the data base Once the
transaction has been committed, all the updates that is performed are in the data base
pointed to by db – pointer. Thus either all the updates of the transaction are reflected or
none of the effects are reflected, regardless of the transaction failure.

ABOUT System failure:

If the system fails at any time before the updated pointer is written to the disk. When system
restart , it will read db – pointer and will thus see the original content of the data base and
none of the effect of the transaction will be visible on the data base

If the system fails after the db- pointer has been update on the disk. Before the pointer is
updated all the upgrade pages of the new database were written to the disk. It will read db-
pointer and will thus see the contents of the data base after all the updates performed by
the transaction.

Thus atomicity and durability of the transaction are ensured by the shadow copy

Assumes disks to not fail. Useful for text editors, but extremely inefficient for large databases:
executing a single transaction requires copying the entire database. Will see better schemes.

Multiple transactions are allowed to run concurrently in the system. Advantages are:

increased processor and disk utilization, leading to better transaction throughput: one
transaction can be using the CPU while another is reading from or writing to the disk

reduced average response time for transactions: short transactions need not wait behind
long ones.

Concurrency control schemes – mechanisms to achieve isolation, i.e., to control the

interaction among the concurrent transactions in order to prevent them from destroying the
consistency of the database
View Serializability
o A schedule will view serializable if it is view equivalent to a serial schedule.
o If a schedule is conflict serializable, then it will be view serializable.
o 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.

Above two schedules are view equivalent because Initial read operation in S1 is done
by T1 and in S2 it is also done by T1.
2. Updated Read

Above two schedules are not view equal because, in S1, T3 is reading A updated by
T2 and in S2, T3 is reading A updated by T1.

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.

Above two schedules is view equal because Final write operation in S1 is done by T3
and in S2, the final write operation is also done by T3.
Example:

Schedule S

With 3 transactions, the total number of possible schedule

3! = 6
1. S1 = <T1 T2 T3>
2. S2 = <T1 T3 T2>
3. S3 = <T2 T3 T1>
4. S4 = <T2 T1 T3>
5. S5 = <T3 T1 T2>
6. S6 = <T3 T2 T1>

Taking first schedule S1:

Schedule S1

Step 1: final up dation on data items

In both schedules S and S1, there is no read except the initial read that's why we
don't need to check that condition.

Step 2: Initial Read

The initial read operation in S is done by T1 and in S1, it is also done by T1.

Step 3: Final Write

The final write operation in S is done by T3 and in S1, it is also done by T3. So, S and
S1 are view Equivalent.

The first schedule S1 satisfies all three conditions, so we don't need to check another
schedule.

Hence, view equivalent serial schedule is:

1. T1 → T2 → T3

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.

The above 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, but T2 can't be rollback because it already committed.
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.

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.

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.
Concurrency problems in DBMS
Transactions
When multiple transactions execute concurrently in an uncontrolled or
unrestricted manner, then it might lead to several problems. These problems
are commonly referred to as concurrency problems in a database
environment. The five concurrency problems that can occur in the database
are:

 Temporary Update Problem

 Incorrect Summary Problem
 Lost Update Problem
 Unrepeatable Read Problem
 Phantom Read Problem

Temporary Update Problem:

Temporary update or dirty read problem occurs when one transaction
updates an item and fails. But the updated item is used by another
transaction before the item is changed or reverted back to its last value.
Example:

In the above example, if transaction 1 fails for some reason then X will revert
back to its previous value. But transaction 2 has already read the incorrect
value of X.

Incorrect Summary Problem:

Consider a situation, where one transaction is applying the aggregate
function on some records while another transaction is updating these
records. The aggregate function may calculate some values before the
values have been updated and others after they are updated.
Example:
In the above example, transaction 2 is calculating the sum of some records
while transaction 1 is updating them. Therefore the aggregate function may
calculate some values before they have been updated and others after they
have been updated.

Lost Update Problem:

In the lost update problem, an update done to a data item by a transaction is
lost as it is overwritten by the update done by another transaction.
Example:

In the above example, transaction 2 changes the value of X but it will get
overwritten by the write commit by transaction 1 on X (not shown in the
image above). Therefore, the update done by transaction 2 will be lost.
Basically, the write commit done by the last transaction will overwrite all
previous write commits.
Unrepeatable-repeatable Read Problem:
The unrepeatable problem occurs when two or more read operations of the
same transaction read different values of the same variable.
Example:
In the above example, once transaction 2 reads the variable X, a write
operation in transaction 1 changes the value of the variable X. Thus, when
another read operation is performed by transaction 2, it reads the new value
of X which was updated by transaction 1.

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.
Example:
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.
Recoverability in DBMS
Crash Recovery
DBMS is a highly complex system with hundreds of transactions being executed every
second. The durability and robustness of a DBMS depends on its complex architecture and its
underlying hardware and system software. If it fails or crashes amid transactions, it is
expected that the system would follow some sort of algorithm or techniques to recover lost
data.

Failure Classification
To see where the problem has occurred, we generalize a failure into various categories, as
follows −

Transaction failure
A transaction has to abort when it fails to execute or when it reaches a point from where it
can’t go any further. This is called tr ansaction failure where only a few transactions or
processes are hurt.
Reasons for a transaction failure could be −
  Logical errors − Where a transaction cannot complete because it has some
code error or any internal error condition.
 System errors − Where the database system itself terminates an active
transaction because the DBMS is not able to execute it, or it has to stop
because of some system condition. For example, in case of deadlock or
resource unavailability, the system aborts an active transaction.
System Crash
There are problems − external to the system − that may cause the system to stop abruptly and
cause the system to crash. For example, interruptions in power supply may cause the failure
of underlying hardware or software failure.
Examples may include operating system errors.

Disk Failure
In early days of technology evolution, it was a common problem where hard-disk drives or
storage drives used to fail frequently.
Disk failures include formation of bad sectors, unreachability to the disk, disk head crash or
any other failure, which destroys all or a part of disk storage.

Storage Structure
We have already described the storage system. In brief, the storage structure can be divided
into two categories −
 Volatile storage − As the name suggests, a volatile storage cannot survive
system crashes. Volatile storage devices are placed very close to the CPU;
normally they are embedded onto the chipset itself. For example, main
memory and cache memory are examples of volatile storage. They are fast but
can store only a small amount of information.
 Non-volatile storage − These memories are made to survive system crashes.
They are huge in data storage capacity, but slower in accessibility. Examples
may include hard-disks, magnetic tapes, flash memory, and non-volatile
(battery backed up) RAM.

Recovery and Atomicity

When a system crashes, it may have several transactions being executed and various files
opened for them to modify the data items. Transactions are made of various operations,
which are atomic in nature. But according to ACID properties of DBMS, atomicity of
transactions as a whole must be maintained, that is, either all the operations are executed or
none.
When a DBMS recovers from a crash, it should maintain the following −
 It should check the states of all the transactions, which were being executed.
 A transaction may be in the middle of some operation; the DBMS must ensure
the atomicity of the transaction in this case.
 It should check whether the transaction can be completed now or it needs to be
rolled back.
  No transactions would be allowed to leave the DBMS in an inconsistent state.

Transaction Isolation
In order to determine if a transaction is Serializable or not we need some thorough
analysis of transactions. We cannot simply say any serial schedule transactions are
conflicting or view Serializable. In order to determine their serializability and
hence their isolation, we use precedence graph. This is a directed graph, from one
transaction to another. A directed node between any two transactions is drawn if
there is any conflict between them.

Consider below case and the precedence graph for the same. Draw nodes for each
transaction. Draw a directed line from T1 to T2 (T1 T2) if T2 reads the data x after
T1 writes it, or if T2 writes x after T1 reads it.

For any schedule to be conflict Serializable, the precedence graph should be like
T1 → T2 → T4 → T5 → T3 (order of transaction can be anything, but it should
not form cycle). That means transactions can be serialized even if they have
conflicting transactions, and can achieve isolation.
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).

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

For example:
Explanation:

Read(A): In T1, no subsequent writes to A, so no new edges

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

Precedence graph for schedule S1:

The precedence graph for schedule S1 contains a cycle that's why Schedule S1 is
non-serializable.
Explanation:

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

Precedence graph for schedule S2:

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

Conflict Serializable Schedule

o A schedule is called conflict serializability if after swapping of non-conflicting
operations, it can transform into a serial schedule.
o 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.

Example:
Swapping is possible only if S1 and S2 are logically equal.

Here, S1 = S2. That means it is non-conflict.

Here, S1 ≠ S2. That means it is conflict.

Conflict Equivalent
In the conflict equivalent, one can be transformed to another by swapping non-
conflicting operations. In the given example, S2 is conflict equivalent to S1 (S1 can be
converted to S2 by swapping non-conflicting operations).

Two schedules are said to be conflict equivalent if and only if:

1. They contain the same set of the transaction.

2. If each pair of conflict operations are ordered in the same way.

Example:

Schedule S2 is a serial schedule because, in this, all operations of T1 are performed

before starting any operation of T2. Schedule S1 can be transformed into a serial
schedule by swapping non-conflicting operations of S1.

After swapping of non-conflict operations, the schedule S1 becomes:

T1 T2
Read(A)
Write(A)
Read(B)
Write(B)
Read(A)
Write(A)
Read(B)
Write(B)

Since, S1 is conflict serializable.

Lock-Based Protocol
In this type of protocol, any transaction cannot read or write data until it acquires an
appropriate lock on it. There are two types of lock:

1. Shared lock:

o It is also known as a Read-only lock. In a shared lock, the data item can only
read by the transaction.
o It can be shared between the transactions because when the transaction holds
a lock, then it can't update the data on the data item.

2. Exclusive lock:

o In the exclusive lock, the data item can be both reads as well as written by the
transaction.
o This lock is exclusive, and in this lock, multiple transactions do not modify the
same data simultaneously.

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 the transaction.

2. Pre-claiming Lock Protocol

o Pre-claiming Lock Protocols evaluate the transaction to list all the data items
on which they need locks.
o Before initiating an execution of the transaction, it requests DBMS for all the
lock on all those data items.
o If all the locks are granted then this protocol allows the transaction to begin.
When the transaction is completed then it releases all the lock.
o If all the locks are not granted then this protocol allows the transaction to rolls
back and waits until all the locks are granted.

3. Two-phase locking (2PL)

o The two-phase locking protocol divides the execution phase of the transaction
into three parts.
o In the first part, when the execution of the transaction starts, it seeks
permission for the lock it requires.
o In the second part, the transaction acquires all the locks. The third phase is
started as soon as the transaction releases its first lock.
 o In the third phase, the transaction cannot demand any new locks. It only
releases the acquired locks.

There are two phases of 2PL:

Growing phase: In the growing phase, a new lock on the data item may be acquired
by the transaction, but none can be released.

Shrinking phase: In the shrinking phase, existing lock held by the transaction may
be released, but no new locks can be acquired.

In the below example, if lock conversion is allowed then the following phase can
happen:

1. Upgrading of lock (from S(a) to X (a)) is allowed in growing phase.

2. Downgrading of lock (from X(a) to S(a)) must be done in shrinking phase.

Example:
The following way shows how unlocking and locking work with 2-PL.

Transaction T1:

o Growing phase: from step 1-3

o Shrinking phase: from step 5-7
o Lock point: at 3

Transaction T2:

o Growing phase: from step 2-6

o Shrinking phase: from step 8-9
o Lock point: at 6

4. Strict Two-phase locking (Strict-2PL)

 o The first phase of Strict-2PL is similar to 2PL. In the first phase, after acquiring
all the locks, the transaction continues to execute normally.
o The only difference between 2PL and strict 2PL is that Strict-2PL does not
release a lock after using it.
o Strict-2PL waits until the whole transaction to commit, and then it releases all
the locks at a time.
o Strict-2PL protocol does not have shrinking phase of lock release.

It does not have cascading abort as 2PL does.

Timestamp Ordering Protocol

o 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.
o 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.
 o 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.
o 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.
o The timestamp ordering protocol also maintains the timestamp of last 'read'
and 'write' operation on a data.

Basic Timestamp ordering protocol works as follows:

1. Check the following condition whenever a transaction Ti issues a Read

(X) operation:

o If W_TS(X) >TS(Ti) then the operation is rejected.

o If W_TS(X) <= TS(Ti) then the operation is executed.
o Timestamps of all the data items are updated.

2. Check the following condition whenever a transaction Ti issues

a Write(X) operation:

o If TS(Ti) < R_TS(X) then the operation is rejected.

o If TS(Ti) < W_TS(X) then the operation is rejected and Ti is rolled back
otherwise the operation is executed.

Where

TS(TI) denotes the timestamp of the transaction Ti.

R_TS(X) denotes the Read time-stamp of data-item X.

W_TS(X) denotes the Write time-stamp of data-item X.

Advantages and Disadvantages of Protocol:

o Protocol ensures serializability since the precedence graph is as follows:
 o TS protocol ensures freedom from deadlock that means no transaction ever
waits.
o But the schedule may not be recoverable and may not even be cascade- free.

Validation Based Protocol

Validation phase is also known as optimistic concurrency control technique. In the
validation based protocol, the transaction is executed in the following three phases:

1. Read phase: In this phase, the transaction T is read and executed. It is used to
read the value of various data items and stores them in temporary local
variables. It can perform all the write operations on temporary variables
without an update to the actual database.
2. Validation phase: In this phase, the temporary variable value will be validated
against the actual data to see if it violates the serializability.
3. Write phase: If the validation of the transaction is validated, then the
temporary results are written to the database or system otherwise the
transaction is rolled back.

Here each phase has the following different timestamps:

Start(Ti): It contains the time when Ti started its execution.

Validation (Ti): It contains the time when Ti finishes its read phase and starts its
validation phase.

Finish(Ti): It contains the time when Ti finishes its write phase.

 o This protocol is used to determine the time stamp for the transaction for
serialization using the time stamp of the validation phase, as it is the actual
phase which determines if the transaction will commit or rollback.
o Hence TS(T) = validation(T).
o The serializability is determined during the validation process. It can't be
decided in advance.
o While executing the transaction, it ensures a greater degree of concurrency
and also less number of conflicts.
o Thus, it contains transactions which have less number of rollbacks.

Thomas write Rule

Thomas Write Rule provides the guarantee of serializability order for the protocol. It
improves the Basic Timestamp Ordering Algorithm.

The basic Thomas write rules are as follows:

o If TS(T) < R_TS(X) then transaction T is aborted and rolled back, and operation
is rejected.
o If TS(T) < W_TS(X) then don't execute the W_item(X) operation of the
transaction and continue processing.
o If neither condition 1 nor condition 2 occurs, then allowed to execute the
WRITE operation by transaction Ti and set W_TS(X) to TS(T).

If we use the Thomas write rule then some serializable schedule can be permitted
that does not conflict serializable as illustrate by the schedule in a given figure:

Figure: A Serializable Schedule that is not Conflict Serializable

In the above figure, T1's read and precedes T1's write of the same data item. This
schedule does not conflict serializable.
Thomas write rule checks that T2's write is never seen by any transaction. If we delete
the write operation in transaction T2, then conflict serializable schedule can be
obtained which is shown in below figure.

Figure: A Conflict Serializable Schedule

Multiple Granularity
Let's start by understanding the meaning of granularity.

Granularity: It is the size of data item allowed to lock.

Multiple Granularity:

o It can be defined as hierarchically breaking up the database into blocks which

can be locked.
o The Multiple Granularity protocol enhances concurrency and reduces lock
overhead.
o It maintains the track of what to lock and how to lock.
o It makes easy to decide either to lock a data item or to unlock a data item.
This type of hierarchy can be graphically represented as a tree.

For example: Consider a tree which has four levels of nodes.

o The first level or higher level shows the entire database.

o The second level represents a node of type area. The higher-level database
consists of exactly these areas.
o The area consists of children nodes which are known as files. No file can be
present in more than one area.
o Finally, each file contains child nodes known as records. The file has exactly
those records that are its child nodes. No records represent in more than one
file.
 o Hence, the levels of the tree starting from the top level are as follows:
1. Database
2. Area
3. File
4. Record

In this example, the highest level shows the entire database. The levels below are file,
record, and fields.

There are three additional lock modes with multiple granularity:

Intention Mode Lock

Intention-shared (IS): It contains explicit locking at a lower level of the tree but only
with shared locks.
Intention-Exclusive (IX): It contains explicit locking at a lower level with exclusive or
shared locks.

Shared & Intention-Exclusive (SIX): In this lock, the node is locked in shared mode,
and some node is locked in exclusive mode by the same transaction.

Compatibility Matrix with Intention Lock Modes: The below table describes the
compatibility matrix for these lock modes:

It uses the intention lock modes to ensure serializability. It requires that if a

transaction attempts to lock a node, then that node must follow these protocols:

o Transaction T1 should follow the lock-compatibility matrix.

o Transaction T1 firstly locks the root of the tree. It can lock it in any mode.
o If T1 currently has the parent of the node locked in either IX or IS mode, then
the transaction T1 will lock a node in S or IS mode only.
o If T1 currently has the parent of the node locked in either IX or SIX modes,
then the transaction T1 will lock a node in X, SIX, or IX mode only.
o If T1 has not previously unlocked any node only, then the Transaction T1 can
lock a node.
o If T1 currently has none of the children of the node-locked only, then
Transaction T1 will unlock a node.

Observe that in multiple-granularity, the locks are acquired in top-down order, and
locks must be released in bottom-up order.

o If transaction T1 reads record Ra9 in file Fa, then transaction T1 needs to lock
the database, area A1 and file Fa in IX mode. Finally, it needs to lock Ra2 in S
mode.
o If transaction T2 modifies record Ra9 in file Fa, then it can do so after locking
the database, area A1 and file Fa in IX mode. Finally, it needs to lock the Ra9 in
X mode.
o If transaction T3 reads all the records in file Fa, then transaction T3 needs to
lock the database, and area A in IS mode. At last, it needs to lock Fa in S mode.
o If transaction T4 reads the entire database, then T4 needs to lock the database
in S mode.