In today’s world we are relying on data and for managing data, we have a database management system also known as DBMS. In this, there are many transactions that are taking place concurrently. Transactions are nothing but the operations that we are performing so millions of transactions are occurring together so how do we manage all these transactions as some of them might interfere with others ones during their execution? To manage these types of problems we have scheduling algorithms and there are many types of schedules available. While moving further in this article we will learn which schedule is categorized as a strict schedule, and much more.
What is a Schedule?
Speaking simply the schedule can be understood as a timetable or plan that outlines or manages the activities, events, or tasks that have to be completed in a given time. In DBMS we have transactions in place of activities and events. The schedules can be classified based on various parameters but the general classification is serial and nonserial schedules the rest of the further classifications can be deduced from these two.
Which Schedule is Categorised as a Strict Schedule?
In this section, we will discuss the questions about which schedule is categorized as a strict schedule. The answer to the above question is the recoverable schedule. We can understand the recoverable schedule as the schedule where the current transaction is committed only after all the transactions from which the current transaction is reading are committed. They are known as recoverable because we can recover the system in case of transaction failure to the last committed state by suing the redo and undo statements. And there is no room for change in these rules and because of this, it is categorized as a strict schedule.
Types of Schedules
There are mainly two types of schedules and they can be further classified into various types. The two types are:
- Serial Schedule
- Non-Serial Schedule
Serial Schedule
As the name suggests serial schedules are those types of schedules that work in serial order means that in order for a transaction to start all the previous transactions must have been completed. At a time only one transaction can run as the other will not run till it is not completed.
Non-Serial Schedule
By the name you can get the idea that they are not doing what serial schedules are doing. They can execute any number of transactions at any time without waiting for any other transactions. Unlike serial schedules, they do not have to wait for the previous transaction to finish in order to start a new transaction.
Serializability
It can be understood as a technique that is able to check which of all non-serial schedules are maintaining the consistency of the database. There are many methods to achieve this with non-serial schedules as serial schedules are always serializable.
To learn more about reliability and above mentioned types of schedules you can refer to Serializability in DBMS.
Recoverable Schedule
These are included in the nonserial schedule. These are the type of schedules that are very helpful in case of transaction failure as by the name you can assume that we can recover the state of the database in this transaction. So when a transaction fails you can recover the last committed state of the database where the transaction was started or last committed by using the undo-redo operations.
| T1 | T2 |
|---|---|
| R(A) | |
| W(A) | |
| W(A) | |
| R(A) | |
| commit | |
| commit |
The above is a recoverable schedule as T1 commits before T2 so the T2 will read the correct value.
The recoverable schedules are categorized into three parts.
- Cascading Schedule
- Cascadeless schedule
- Strict Schedule
Cascading Schedule
In this schedule when there is a failure in one transaction and it has rolled back then all the other dependent transactions on that transaction will have to roll back.
Here Transaction T3 depends on T2 and the T2 depends on T1 so the failure in T1 leads to T2 rolling back and is similar for T3.
Cascadeless Schedule
In this if a transaction fails it does not lead the other transactions to fail as here no transaction is not allowed to read from any other transaction unless the last transaction in execution is committed or aborted. It saves CPU time and also prevents the Cascadeless Schedule. As there is no rolling back. We achieve this with the help of locks and various other synchronization methods to prevent the transaction from reading the data of other in-progress transactions.
Here the T2 will read the value after T1 is committed and the same with T3 hence it is a cascade-less schedule.
Strict Schedule
A strict schedule is a schedule in which the order of transactions is preserved exactly as specified by the program or user. Strict schedules are usually not efficient, but they guarantee the integrity and consistency of the data.
| T1 | T2 |
|---|---|
| R(X) | |
| R(X) | |
| W(X) | |
| commit | |
| W(X) | |
| R(X) | |
| commit |
Here the T2 writes the read value of T1 only after T1 is committed hence it is a strict schedule.
Applications of Strict Schedules
There are many applications for strict schedules some of which are mentioned below.
- They are used to maintain the serializability of the transaction. It will ensure that the final state of the database is the same as that of the starting.
- They are used for deadlock avoidance as deadlock occurs when two or more transactions are waiting for resources but with strict schedules, we can implement strict rules to ensure that it does not happen.
- The database can be recovered to last consistent state with the help of strict schedules.
Conclusion
There are many types of schedules present in DBMS we have discussed some of them and along with that we have also answered the questions of the question of which schedule is categorised as a strict schedule and the answer is Recoverable schedule. We can use recoverable schedules in many scenarios and theta re further classified into three types we have discussed all those three types also and at last, we have discussed the applications of strict schedules in DBMS.
Frequently Asked Questions
Below are some of the frequently asked questions about the strict schedule.
1. What do you mean by concurrent schedule?
Concurrent schedule refers to the type of schedule where multiple transactions can run simultaneously.
2. What do you understand by dirty read?
It is a condition when a transaction has read the data that has been modified by the uncommitted transaction.
3. What do you mean by write operation?
This is an operation that modifies the data in the database.
4. What is conflict in DBMS?
A conflict is a situation in which two transactions access the same data item and at least one of them modifies it.