Scribd
Upload
18 views

Strict Serializability and Strict Recoverability of A Schedule

1. Strict serializability and strict recoverability are concepts used to ensure consistency when multiple transactions execute concurrently in a database. 2. A schedule is serializable if its operations are equivalent to a serial schedule, where transactions complete one at a time. Strict serializability further requires that sub-operations within a transaction do not interleave with other transactions. 3. For a schedule to be strictly recoverable, a dependent transaction must read or write only data committed by transactions it depends on, avoiding cascading rollbacks if failures occur.

Uploaded by

Yared Arega
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
18 views

Strict Serializability and Strict Recoverability of A Schedule

1. Strict serializability and strict recoverability are concepts used to ensure consistency when multiple transactions execute concurrently in a database. 2. A schedule is serializable if its operations are equivalent to a serial schedule, where transactions complete one at a time. Strict serializability further requires that sub-operations within a transaction do not interleave with other transactions. 3. For a schedule to be strictly recoverable, a dependent transaction must read or write only data committed by transactions it depends on, avoiding cascading rollbacks if failures occur.

Uploaded by

Yared Arega
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 18

STRICT SERIALIZABILITY

AND STRICT
RECOVERABILITY OF A
SCHEDULE
ORACLE AND MS-SQL DBMS

1. Betelhem Mulugeta
2. Hayat Ramadan
3. Kalkidan Dereje
4. Yordanos Tsegaye
Transaction Concept
• A transaction is a unit of program execution that accesses and possibly
updates various data items.
• A transaction must see a consistent database.
• During transaction execution the database may be inconsistent.
• When the transaction is committed, the database must be consistent.
• Two main issues to deal with:
*Failures of various kinds, such as hardware failures and system
Crashes
*Concurrent execution of multiple transactions
SCHEDULES

A schedule is a time order sequence of two or more transactions.


The scheduler decides the execution order of concurrent database
accesses.

CLASSIFICATION OF SCHEDULES
Schedules can be classified as on the basis of two types,
• On the basis of Serializability
• On the basis of Recoverability
SERIALIZABILITY
When multiple transactions run concurrently, then it may give rise to
inconsistency of the database.

Serializability is a concept that helps to identify which non-serial


schedules are correct and will maintain the consistency of the
database.
SERIALIZABILITY

To ensure consistency of database we make are that concurrent


schedules should be in some sense equivalent to a serial
schedule. The concept of schedules is used to identify which
solutions are correct when transactions have interleaving of their
operations in schedules. A schedule is said to be serializable if
either it is conflict serializable, view serializable or both.
EXAMPLE
T1 T2 In this situation, the two transactions
R(A) do not have operations on the same
W(A) data item, so the schedule is
R(B) serializable.
W(B)
R(C) A serializable schedule is a schedule
W(C) whose effect on any consistent
Commit database instance is guaranteed to be
Commit
identical to that of some complete
serial schedule over S.
• Strict Sirializability of schedule
T1 T2
Strict serializability is a transactional model
R(X)
operations (usually termed “transactions”)
can involve several primitive operations
W(X) R(Y) performed in order.

Commit Strict serializability guarantees that


operations take place atomically: a
W(X) transaction’s sub-operations do not appear
to interleave with sub-operations from
R(X)
other transactions.
• Is Strict Serialiability Schedule the same as Serial Schedule?
=> NO!! Although All serial Schedule are Strict Serialiability schedule
T1 T2 T1 T2
R(X) R(X)
W(X) W(X) R(Y)
Commit Commit
W(X) W(X)
R(X) R(X)

Serial schedule Strict Serialiability


RECOVERABILITY
If a transaction Ti reads a data items written by a transaction Tj,
the commit operation of Tj must occur before the commit of Ti.
Classification of Schedules on the basis of
recoverability
1. Irrecoverable Schedule
If we need to Rollback a committed transaction
EXAMPLE

T1 T2
R(A)
W(A)
R(A)
W(A)
Rollback W(A) COMMIT
2. Cascading Rollback
It is a type of Rollback, when because of the Rollback of one
transaction, Rollback of many other transaction is caused.

T1 T2 T3 T4
EXAMPLE
W(A)
R(A)
W(A)
R(A)
W(A)
R(A)
W(A)
Rollback

Rollback of T1 causes the Rollback of all T1,T2,T3 and T4


The solution would be making the previous schedule Cascading
Recoverable Schedule
T1 T2 T3 T4
W(A)
Commit
R(A)
W(A)
Commit
R(A)
W(A)
Commit
R(A)
W(A)
Commit
3. Strict Recoverability
T1 T2
R(A)
Independent W(A) Dependent
transaction Commit Transaction
R(A)
W(A)

The Dependent Transaction Should read or write only after the


commit of the Independent Transaction (T1)
HOW TO ACHIEVE RECOVERY
• S is recoverable if each transaction commits only after all transactions
from which it read have committed.

• S avoids cascading rollback if each transaction may read only those


values written by committed transactions.

• S is strict if each transaction may read and write only items previously
written by committed transactions.
• S is recoverable if each transaction commits only after
all transactions from which it read have committed.
• Allows dirty read
• S avoids cascading rollback if each transaction may read
only those values written by committed transactions.
• Disallows dirty read

• S is strict if each transaction may read and write only


items previously written by committed transactions.
1. R1(X),W1(X),R1(Y),W1(Y),C1,R2(X),W2(X),C2 Strict
2.R2(X),R1(X),W1(X),R1(Y),W1(Y),C1,W2(X),C2 Strict
3.R1(X),W1(X),R1(Y),W1(Y),R2(X),W2(X),C2,C1 Non
Recoverable

You might also like