Scheduling of Transactions
Let's delve into each concept in detail, using examples where appropriate:
Schedule in Database Management:
A schedule is a sequence of execution of operations from various transactions in a database system. It defines the order in which transactions are executed. Scheduling is essential because when multiple transactions execute concurrently, they can affect each other's results. Let's explore different types of schedules:
Serial Schedule:
In a serial schedule, transactions are executed one after another, in a predefined order.
This guarantees that transactions do not interfere with each other.
Example:
Transaction T1: Transfer $100 from Account A to Account B.
Transaction T2: Withdraw $50 from Account A.
In a serial schedule, T1 would complete before T2 starts, ensuring consistency.
Non-Serial Schedule:
In a non-serial schedule, transactions can execute in any order.
This increases concurrency but introduces the potential for conflicts.
Example:
If T1 and T2 can execute in any order, they might conflict if not properly managed.
Recoverable and Non-Recoverable Schedule:
These schedules relate to the commitment of transactions.
In recoverable schedules, transactions commit only after all transactions whose changes they depend on have committed.
In non-recoverable schedules, there is no such strict requirement.
Example:
Suppose T2 reads data modified by T1. In a recoverable schedule, T2 can only commit after T1 commits, ensuring that T2's actions are based on stable data.
In a non-recoverable schedule, T2 might commit before T1, potentially leading to issues if T1 rolls back.
Cascading Abort and Cascadeless Schedule:
These concepts deal with the consequences of transaction failures.
In cascading abort, the failure of one transaction leads to the rollback or abort of other dependent transactions.
In a cascadeless schedule, transactions are not allowed to read data until the last transaction that wrote it is committed or aborted.
Example:
If T1 fails in a cascading abort scenario, it may force T2 and T3 to also roll back.
In a cascadeless schedule, T2 cannot read data modified by T1 until T1 commits or aborts, preventing cascading issues.
Strict Schedule:
A strict schedule is even more restrictive than a cascadeless schedule.
In a strict schedule, a transaction is neither allowed to read nor write a data item until the last transaction that has written it is committed or aborted.
Example:
T2 cannot read or write data until T1 is fully completed, ensuring the highest level of data consistency.
Transaction Control:
These commands manage transaction execution:
COMMIT: The COMMIT command saves changes made by the transaction in the database.
Example:
COMMIT;saves all changes made by the current transaction.
ROLLBACK: The ROLLBACK command undoes saved changes made by the transaction, restoring the database to its previous state.
Example:
ROLLBACK;reverses all changes made by the current transaction.
SAVEPOINT: SAVEPOINT is a point within a transaction where it can be rolled back without affecting the entire transaction.
Example:
SAVEPOINT point1;creates a savepoint within the transaction.
Concurrency Control:
Concurrency control protocols manage access to shared data in a multi-user database environment:
Lock-Based Protocol:
In a lock-based protocol, a transaction locks a data item it wants to access, preventing others from accessing it concurrently.
Other transactions must wait until the lock is released.
Example:
T1 locks a record before updating it, preventing T2 from accessing it until T1 releases the lock.
Time Stamp Based Protocol:
Time stamp-based protocol uses timestamps to serialize the execution of concurrent transactions.
It ensures that conflicting read and write operations are executed in timestamp order.
Example:
Transactions are assigned timestamps, and the system ensures that operations are carried out based on these timestamps to maintain consistency.
Last updated
Was this helpful?