Introduction
A schedule is the presentation of transaction operations. Scheduling is brought into play when multiple transactions are running concurrently. The order of process must be set so that the procedures do not overlap and the transactions are timed accordingly. It maintains the order of the operation in each transaction.
Types of Schedules
The categories of schedules are given below in the form of a chart.
Serial Schedules
Schedules in which the transactions do not start execution until the currently running transaction is finished are serial schedules.
Example:
| T1 | T2 |
| Read(A) | |
| Read(B) | |
| Write(A) | |
| commit | |
| Read(B) | |
| Read(A) | |
| Write(A) | |
| commit |
Here R means read operation, and W means write operation. In this example, transaction T2 does not start execution until transaction T1 is finished.
Non-Serial Schedules
Schedules in which the transactions execute parallel at a time is known as non-serial Schedule.
Example:
| T1 | T2 |
| Read1(P) | |
| Write1(P) | |
| Read2(Q) | |
| Write2(Q) | |
| Read1(Q) | |
| Write1(Q) | |
| Read1(Q) |
Further Non-serial schedules are divided into two types:-
-
Serializable
This is mainly used to maintain the consistency of the Database. It is mainly used in Non-Serial scheduling to verify whether the scheduling will lead to any inconsistency or not. A serial schedule does not need serializability because it follows a transaction only when the previous transaction is complete.
These are of two types:
1. Conflict-serializable
If a schedule can be converted into a serial by swapping non-conflicting operations is known as conflict serializable. If all conditions are satisfied that are mentioned below, then procedures are considered as conflicting:
- one of them is a write operation.
- They operate on the same data item.
- They belong to different transactions.
2. View-serializable
A schedule is known as a view serializable if it is view equivalent to a serial schedule. A conflict schedule is a view serializable, but if the serializability contains blind writes, then the view serializable schedule is not a conflict serializable schedule.
-
Non-serializable
It does not guarantee to produce the same effect as produced by some serial schedules on any consistent database.
It is further classified into two types:
1. Recoverable
In recoverable Schedules, transactions commit only after all transactions whose changes they read commit. In other words, if some transaction Tk is reading value updated or written by some other transaction Tj, then the commit of Tk must occur after the commit of Tj.
Consider the following Schedule involving two transactions, T1 and T2.
| T1 | T2 |
| Read(A) | |
| Write(A) | |
| Write(A) | |
| Read(A) | |
| commit | |
| commit |
This is a recoverable schedule since T1 commits before T2, which makes the value read by T2 correct.
2. Non-Recoverable
Suppose a transaction performs a dirty read from the uncommitted transaction in a schedule and commits only before the transaction has read values. In that case, such a schedule is known as an irrecoverable schedule.
| T1 | T2 |
| Read(A) | |
| Write(A) | |
| Write(A) | |
| Read(A) | |
| commit | |
| abort |
T2 reads A written by T1 and commits it, and T1 later aborted, and hence, the value read by T2 is wrong, but since T2 committed, this Schedule is non-recoverable.
You can also read about the Log based recovery.
Must Recommended Topic, Schema in DBMS
18+ registered 
