Transactions & Concurrency

Transaction & Operations

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

Read Operation - Read(A) instruction will read the value of ‘A’ from the database and will store it in the buffer in main memory.
Write Operation – Write(A) will write the updated value of ‘A’ from the buffer to the database.

Transaction States

A transaction goes through several states during its lifecycle:

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.
Partially Committed State – After the last instruction of the transaction has been executed, it enters into a partially committed 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.
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.
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.
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.
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

To ensure the consistency of the database, certain properties are followed by all the transactions occurring in the system. These properties are called as ACID Properties of a transaction.

Atomicity – This property ensures that either the transaction occurs completely or it does not occur at all. In other words, it ensures that no transaction occurs partially.
Consistency – This property ensures that integrity constraints are maintained. In other words, it ensures that the database remains consistent before and after the transaction.
Isolation – This property ensures that multiple transactions can occur simultaneously without causing any inconsistency. The resultant state of the system after executing all the transactions is the same as the state that would be achieved if the transactions were executed serially one after the other.
Durability – This property ensures that all the changes made by a transaction after its successful execution are 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.

Schedules & Serializability

The order in which the operations of multiple transactions appear for execution is called as a schedule.

Serial Schedules – All the transactions execute serially one after the other. When one transaction executes, no other transaction is allowed to execute. Serial schedules are always- Consistent, Recoverable, Cascadeless and Strict.
Non-Serial Schedules – Multiple transactions execute concurrently. Operations of all the transactions are inter leaved or mixed with each other. Non-serial schedules are not always- Consistent, Recoverable, Cascadeless and Strict.
Serializability – Serializability is a concept that helps to identify which non-serial schedules are correct and will maintain the consistency of the database.
Serializable Schedules – If a given non-serial schedule of ‘n’ transactions is equivalent to some serial schedule of ‘n’ transactions, then it is called as a serializable schedule. Serializable schedules are always- Consistent, Recoverable, Cascadeless and Strict.

Types of Serializability

Serializability can be categorized into two main types:

Conflict Serializability - If a given non-serial schedule can be converted into a serial schedule by swapping its non-conflicting operations, then it is called a conflict serializable schedule.
View Serializability - If a given schedule is found to be viewed as equivalent to some serial schedule, then it is called a view serializable schedule.

Recoverability of Schedules

Schedules are also classified based on their recoverability:

Irrecoverable Schedules – If in a schedule, a transaction performs a dirty read operation from an uncommitted transaction and commits before the transaction from which it has read the value then such a schedule is known as an Irrecoverable Schedule.
Recoverable Schedules – If in a schedule, a transaction performs a dirty read operation from an uncommitted transaction and its commit operation is delayed till the uncommitted transaction either commits or roll backs then such a schedule is known as a Recoverable Schedule.
Cascading Schedule - If in a schedule, failure of one transaction causes several other dependent transactions to rollback or abort, then such a schedule is called as a Cascading Schedule.
Cascadeless Schedule - If in a schedule, a transaction is not allowed to read a data item until the last transaction that has written it is committed or aborted, then such a schedule is called as a Cascadeless Schedule.
Strict Schedule - If in a schedule, a transaction is neither allowed to read nor write a data item until the last transaction that has written it is committed or aborted, then such a schedule is called as a Strict Schedule.