A transaction is a unit of instruction or set of instructions that performs a logical unit of work. Transaction processes are always atomic in nature either they will execute completely or do not execute.
Transaction Properties:
- Atomicity: Either execute all operations or none of them. It is managed by the transaction Management Component.
- Consistency: Database must be consistent before and after the execution of the transaction. If atomicity, isolation, and durability are implemented accurately, consistency will be achieved automatically.
- Isolation: In concurrent transactions, the execution of one transaction must not affect the execution of another transaction. It is managed by the Concurrency Control component.
- Durability: After the commit operation, the changes should be durable and persist always in the database. It is managed by the Recovery Management component.
Schedule: Sequences in which instructions of the concurrent transactions get executed. Schedules are of two types:
- Serial Schedule: Transactions execute one by one, another transaction will begin after the commit of the first transaction. It is inconsistent and the system’s efficiency is so poor due to no concurrency.
- The number of possible serial schedules with n transactions = n!
- Non-Serial Schedule: When two or more transactions can execute simultaneously. This may lead to inconsistency, but have better throughput and less response time.
∩ (Intersection)Serializability: A schedule is said to be serializable if it is equivalent to a serial schedule. It is categorized into two categories: Conflict Seriablizability, and View Serializability.
Conflict Serializability: A schedule will be conflict serializable if it can be transformed into a serial schedule by swapping non-conflicting operations. It is a polynomial-time problem.
- Conflicting operations: Two operations will be conflicting if****
- They belong to different transactions.
- They are working on the same data item.
- At least one of them is the Write operation.
View Serializability: A schedule will be view serializable if it is view equivalent to a serial schedule. It is an NP-Complete Problem.
- Check whether it is conflict serializable or not, if Yes then it is view serializable.
- If the schedule does not conflict with serializable then check whether it has blind write or not. If it does not have blind write then it is not view serializable. [To be view serializable a schedule must have a blind write]
- If the schedule has blind write, Now check whether the schedule is view-equivalent to any other serial schedule.
- Now, draw a precedence graph using given dependencies. If no cycle/loop exists in the graph, then the schedule would be a View-Serializable otherwise not.
Types of Schedule based recoverability:
- Irrecoverable Schedule: A transaction is impossible to roll back once the commit operation is done.
- **Recoverable Schedule:** A schedule is recoverable if a transaction Ti reads a data item previously written by Transaction Tj, the commit operation Tj appears before the commit operation of Ti.
