Introduction to transaction:

A database transaction is a fundamental concept in database management systems (DBMS)

that ensures the reliable and consistent execution of a set of database operations. It represents
a logical unit of work that is performed as an indivisible and isolated sequence of operations on
a database. In everyday life, we encounter transactions in various scenarios. For example, when
you withdraw money from an ATM, several steps are involved, such as checking your account
balance, deducting the amount, and updating the transaction history.

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 When any instruction of the transaction fails, it goes to the “failed state” or if failure
occurs in making a permanent change of data on Data Base.
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 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.
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.
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
This means that integrity constraints must be maintained so that the database is consistent
before and after the transaction.
Before the transaction starts and after the transaction completed the database should be consistent.

It refers to the correctness of a database. Referring to the example above,

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. As
a result, T is incomplete.

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.

Schedule
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 T1 which was followed by all the operations of T2.

o In the given (a) figure, Schedule A shows the serial schedule where T1 followed by T2.
o In the given (b) figure, Schedule B shows the serial schedule where T2 followed by T1.

2. Non-serial Schedule
o If interleaving of operations is allowed, then there will be non-serial schedule.
o It contains many possible orders in which the system can execute the individual
operations of the transactions.
o 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
o The serializability of schedules is used to find non-serial schedules that allow the
transaction to execute concurrently without interfering with one another.
o It identifies which schedules are correct when executions of the transaction have
interleaving of their operations.
o A non-serial schedule will be serializable if its result is equal to the result of its
transactions executed serially.
Here,

Schedule A and Schedule B are serial schedule.

Schedule C and Schedule D are Non-serial schedule.

Serializability:
Serializability is a concept in database systems that ensures the execution of concurrent
transactions produces the same results as if they were executed serially, one after the
other. In other words, serializability guarantees that the final state of the database is
equivalent to some sequential execution of the transactions. There are two types of
serializability:

Conflict Serializability: Conflict serializability is the most common and widely studied
type of serializability. It ensures that the order of conflicting operations in concurrent
transactions is equivalent to some serial execution order. Conflicting operations are
those that access or modify the same data item and at least one of them is a write
operation.

To determine conflict serializability, the concept of precedence graph or serialization

graph is used. In this graph, each transaction is represented as a node, and there is an
edge from transaction Ti to Tj if there exists a conflicting operation in Ti that precedes a
conflicting operation in Tj. If the precedence graph is acyclic, the schedule is conflict
serializable.

View Serializability: View serializability is a broader notion of serializability that takes

into account the visible effects of transactions, rather than just conflicting operations. It
ensures that the final results of concurrent transactions are equivalent to some serial
execution, regardless of conflicts.

To determine view serializability, the concept of views or snapshots is used.

Concurrency control:
Concurrency control is an essential aspect of database management systems (DBMS) to ensure
that multiple transactions can execute simultaneously without interfering with each other's
operations.
Two commonly used techniques for concurrency control are lock-based and timestamp-based
approaches.
Lock-Based Concurrency Control: In lock-based concurrency control, transactions acquire locks
on database objects (such as records, tables, or pages) to prevent other transactions from
accessing or modifying the same objects concurrently.
This approach involves two types of locks:
Shared Lock (S-lock): Allows concurrent read access to the locked object. Multiple transactions
can hold shared locks on the same object simultaneously.
Exclusive Lock (X-lock): Provides exclusive write access to the locked object. Only one
transaction can hold an exclusive lock on an object at a time, and no other transaction can
acquire any type of lock on that object.
Lock-based concurrency control uses a locking protocol to ensure serializability and prevent
conflicts between transactions. Deadlocks can occur when transactions acquire locks in a way
that creates a circular dependency, causing them to wait indefinitely for each other.
To handle deadlocks, lock-based approaches use techniques such as timeout mechanisms,
deadlock detection, and deadlock resolution (e.g., aborting one or more transactions involved
in the deadlock).
Timestamp-Based Concurrency Control: In timestamp-based concurrency control, each
transaction is assigned a unique timestamp representing its start time. Transactions can read
and write data items based on their timestamps, ensuring that older transactions do not
overwrite or read data modified by newer transactions. Timestamps can be logical (assigned in
increasing order) or physical (based on the actual time of transaction initiation). To enforce
serializability, the DBMS uses the following rules:
Read Rule: A transaction with timestamp T can read an object only if the timestamp of the
transaction that last wrote that object is less than T.
Write Rule: A transaction with timestamp T can write to an object only if no other transaction
has a higher timestamp for that object.
Timestamp-based concurrency control ensures conflict serializability and avoids deadlocks
because transactions do not wait for each other. However, it may lead to certain anomalies like
cascading rollbacks or lost updates. To address these issues, techniques such as strict two-
phase locking (where locks are acquired and released based on timestamps) or multi-version
concurrency control (where multiple versions of an object are maintained) can be employed.

Cascaded aborts:
Cascaded aborts, also known as cascading rollbacks, occur in a database when the abort of one
transaction leads to the abort of other dependent transactions. This situation arises when a
transaction makes modifications to the database and subsequently commits or aborts, causing
other transactions that have read or written the modified data to be affected. Let's understand
cascaded aborts with an example:
Suppose we have three transactions: T1, T2, and T3.
Transaction T1 reads a data item X.
Transaction T2 modifies the same data item X that T1 read.
Transaction T3 reads the modified data item X by T2.
If T1 aborts, it means that the read operation it performed is invalidated. As a result, T2, which
modified the data item X, becomes invalid too. Consequently, T3, which read the modified data
item X from T2, also becomes invalid. Thus, T2 and T3 need to be aborted as well, causing a
cascading effect. Cascaded aborts can have a significant impact on the system's performance
and the correctness of transactions. They can result in a waste of resources and increased
transaction processing time.

Recoverable and non-recoverable schedules:

 Recoverable Schedules: A recoverable schedule means that when a task is finished and saved in the
database, any other tasks that used or read the information from the finished task also have to be
saved. It's like a rule that says, "If you used information from a completed task, you can't undo your
work after that task is finished."
This rule helps maintain the accuracy and consistency of the database. If someone relies on
information from a completed task and then decides to change or undo their work, it could create
confusion and errors because other tasks might have already used that information to make
important decisions.
 Non-Recoverable Schedules: A non-recoverable schedule is the opposite. It means that if someone
used information from a task that was later changed or undone, they can still keep their work and
ignore the changes. It's like saying, "Even if the information you used is no longer valid, you can still
go ahead and keep what you did."
Non-recoverable schedules can be risky because if people base their work on information that ends
up being changed or undone, it can lead to mistakes or inconsistencies in the database. It's generally
better to avoid non-recoverable schedules to ensure data accuracy and prevent confusion.