A schedule is the sequence of actions that connects one transaction to the next. Scheduling is the process of scheduling up transactions and then executing them one by one. If many transactions are running at the same time and the operation order must be determined so that the activities do not conflict with one another, scheduling has been performed, and the transactions are now timed appropriately. In this blog, we will go over many methods of scheduling.
Scheduling as a process
Scheduling is the practice of ensuring that concurrent transactions follow a consistent sequence of events. A timetable is a series of procedures that follow one transaction after another. Transactions are a set of instructions that deal with databases. If many transactions are running at the same time, we require a sequence of how the operations must be performed on the database, as the database can only be operated by one operation at a time. The Scheduling process is as follows: the sequence of these actions is simply scheduling, and this series of operations is known as a schedule. Undefined arrangements of numerous transactions can lead to a variety of problems known as concurrency issues. These issues must be addressed through the scheduling process.
Types of Scheduling Processes
There are mainly two types of scheduling processes and their further sub-types:
i). Serial Schedule
ii). Non-Serial Schedule
Non-Serial Schedules are further divided into two subtypes
Serializable Schedules:
1. Conflict Serializable
2. View Serializable
Non-Serial Schedules
Non-serializable objects are further divided into two subtypes
1. Recoverable Schedules
Cascading Schedules
Strict Schedules
2. Non-Recoverable Schedules
Serial Schedules
A serial schedule is one in which individual implementations of the transactions are not interleaved, that is, no transaction begins until a running transaction has ended. There are two Transactions in this Serial Schedule: T1 and T2. T2 begins operating on variable Z before T1 completes a set of operations to read and write data for its variables X and Y. This will ensure that T1 does not conflict with T2 and that no action is performed before another.
Non-Serial Schedules
Scheduling is a type of Scheduling in which operations from numerous transactions are interleaved. Such an increase could compound the concurrency problem. The transactions are carried out in a non-serial manner, preserving correctness and the end outcome while meeting the serial schedule. In the serial schedule, one transaction must wait for the other transaction to complete its operation completely, but in the non-serial schedule, the other process proceeds without waiting for the other transaction to finish.
Concurrent transactions have no advantage under such a scheduling. In contrast to a non-serial schedule, T1 and T2 are running concurrently. Assume T1 can read and write variable X, while T2 can read from Y and write to Z. T1 and T2 interleave their processes, allowing parallel transactions to perform concurrently and causing data inconsistencies to balance data consistency issues. There are two sorts of schedules: serializable and non-serializable. An additional distinction is established between the Non-Serial Schedule and the two types:
Serializable
It does so to maintain the database's inconsistent state. Its primary purpose is to determine whether scheduling will result in inconsistency. However, serial schedules do not require serializability because a transaction proceeds only after the previous transaction has completed. A serial schedule is made up of all serial schedules, or non-serial schedules, because only non-serial schedules are equivalent to serial schedules for n transactions. Because concurrency is allowed in this situation, many transactions can run concurrently.
Using a serializable schedule enhances CPU performance and resource utilization. The operations in a Serializable Schedule must be interleaved but provide the same ultimate result as if the schedule were executed serially. For example, assume T1 reads and writes to P, and T2 does the same with Q, reading P subsequently; the impact is the same as if T2 ran after T1, i.e., T2 runs after T1 while retaining consistency.
These are of two types Conflict Serializable
A schedule is conflict serializable if it can be converted to a Serial Schedule by exchanging non-conflicting operations. Transactions are rearranged in Conflict Serializable schedules. One example (among many) is that when T1 reads and writes to variable M and T2 also reads and writes to M, we can rearrange non-conflicting operations so that the entire schedule can be turned into a serial one without changing the outcome. If the following conditions are met, two operations are said to be conflicting:
- Transactions will be entirely different.
- They are both working on the same data item.
- At least one of them involves writing.
View Serializable
A schedule is considered to be serializable if it is viewed as equivalent to a serial schedule (with no overlapping transactions). A view serializable does not conflict with a serializable conflict if the serializability includes blind writes and the conflicting schedule is serializable. A View Serializable schedule ensures that even if the operations are interleaved, we get a valid result. For example, if T1 reads A and writes B, then T2 writes A and reads B, the result is the same as if T1 completed the entire transaction before T2, preserving transaction integrity.
Non- Serializable
In a Non-Serializable Schedule, T1 can now write to A while T2 reads and writes to B. This condition may result in disagreements since T2 relies on uncommitted data in T1, which could lead to incorrect results. The non-serializable schedule determines which schedules are recoverable and which are not.
Recoverable Schedule
And recoverable schedules are those in which transactions may commit only after all transactions that they read have committed. In a Recoverable Schedule, T1 reads and writes to A, followed by T2, who commits. T2 can only commit if T1 has already done so, which is what has happened here. This ensures that if T1 fails or aborts, T2 will essentially roll back its own changes to ensure data uniformity.
There are three types of recoverable schedules
Cascading Schedule
Also known as the avoidance of cascading abortions/rollbacks (ACA). If one of the transactions fails, another dependent transaction is rolled back or aborted. This is referred to as cascading rollback or cascading abort. In the case of a Cascading Schedule, one transaction's outcome influences another. For example, if T1 commits, it may write to A, and T2 will read and write A again. If T3 reads A, it may need to abort, and other transactions may need to roll back their modifications, causing the effect to cascade across several transactions.
Cascadeless Schedules
Cascadeless schedules are those in which transactions read data only after all of the changes they read have been committed. It prevents the consequence of a single transaction abort, resulting in a succession of transaction rollbacks. To avoid cascade aborts, restrict a transaction from reading the uncommitted changes of another transaction in the same schedule. In a Cascadeless Schedule, T1 reads and writes to A, then commits before T2. This structure eliminates cascading rollbacks because T2 only reads committed data from T1; therefore, if T1 fails, T2 can proceed uninterrupted.
Strict Schedule
A strict schedule assures that if one transaction writes a value, subsequent transactions can only read or write that value after the original transaction has committed or aborted. This avoids complications between multiple transactions. A Strict Schedule ensures that no data can be read or written until another transaction has been finished. The first example shows that T1 writes to A and commits before T2 reads from and writes to A. It ensures that T2 only processes finished data and that data integrity is preserved.
Non-Recoverable Schedules
A schedule is said to be non-recoverable if a transaction reads the value of an operation from an unprocessed transaction and accepts before the transaction from which the value was read. If the schedule is unrecoverable during a system breakdown, we may be unable to restore the database to a consistent condition. In a Non-Recoverable Schedule, we can ultimately clock T1 to write A, after which T2 can read from and commit to A. T2 is unrecoverable since it was based on unprocessed data from T1. It demonstrates the dangers of inefficient transaction scheduling.
Conclusion
Schedules are used in DBMSs to regulate the ordering of processes between transactions and ensure consistency. Non-serial schedules support concurrent execution, whereas serial schedules execute transactions sequentially. Conflict serializability indicates that a schedule can be reordered to a serial schedule without conflicts, whereas view serializability indicates that a schedule is equal to a serial schedule. This is critical for assuring transaction consistency in concurrent systems, therefore, both are required.
