Schedule

• A series of operation from one transaction to another transaction is called schedule.

• In other words, it is a process of lining the transactions and executing them one by one.

• When there are multiple transactions that are running in a concurrent manner and the order of operation is needed to be set so that the operations do not overlap each other, Scheduling is brought into play and the transactions are timed accordingly.

Types of Schedule

1. Serial Schedules

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

2. Non-serial Schedules

• This is a type of Scheduling where the operations of multiple transactions are interleaved. This might lead to a rise in the concurrency problem.

• The transactions are executed in a non-serial manner, keeping the end result correct and same as the serial schedule.

• Unlike the serial schedule where one transaction must wait for another to complete all its operation, in the non-serial schedule, the other transaction proceeds without waiting for the previous transaction to complete.

• This sort of schedule does not provide any benefit of the concurrent transaction.

• It can be of two types namely, Serializable and Non-Serializable Schedule.

a. Serializable Schedule:

• This is used to maintain the consistency of the database.

• It is mainly used in the Non-Serial scheduling to verify whether the scheduling will lead to any inconsistency or not.

• Types - Conflict Serializable, View Serializable.

• Conflict Serializable:

• A schedule is called conflict serializable if it can be transformed into a serial schedule by swapping non-conflicting operations.

• Two operations are said to be conflicting if all conditions satisfy:

  • They belong to different transactions
  • They operate on the same data item
  • At Least one of them is a write operation

• View Serializable:

• A schedule will view serializable if it is view equivalent to a serial schedule (no overlapping transactions).
• If a schedule is conflict serializable, then it will be view serializable.
• The view serializable which does not conflict serializable contains blind writes.

b. Non-serializable Schedule:

• A non-serial schedule which is not serializable is called as non-serializable schedule.
• Non-serializable schedules may/may not be consistent or recoverable.

• Non-serializable schedule is divided into types: Recoverable schedule, Non-recoverable schedule

• Recoverable Schedule:

• A schedule is recoverable if each transaction commits only after all the transactions from which it has read has committed. In other words, if some transaction Ty reads value that has been updated/written by some other transaction Tx, then the commit of Ty must occur after the commit of Tx.
• Recoverable schedules are further categorised into 3 types:
  • Cascading Schedule:
  • When there is a failure in one transaction and this leads to the rolling back or aborting other dependent transactions, then such scheduling is referred to as Cascading rollback or cascading abort.
  • Cascadeless Schedule:
  • Schedules in which transactions read values only after all transactions whose changes they are going to read commit are called cascadeless schedules.
  • Strict Schedule:
  • A schedule is strict if for any two transactions Ti, Tj, if a write operation of Ti precedes a conflicting operation of Tj (either read or write), then the commit or abort event of Ti also precedes that conflicting operation of Tj.
  • In other words, Tj can read or write updated or written value of Ti only after Ti commits/aborts.
• Non-recoverable Schedule:
• If a transaction reads the value of an operation from an uncommitted transaction and commits before the transaction from where it has read the value, then such a schedule is called Non-Recoverable schedule.
• A non recoverable schedule means when there is a system failure, we may not be able to recover to a consistent database state. If the commit operation of Ti doesn't occur before the commit operation of Tj, it is non-recoverable.