0% found this document useful (0 votes)
34 views7 pages

DBMS Unit 4 R22

The document outlines the syllabus for a DBMS course focusing on transaction management, concurrency control, and recoverability. It discusses key concepts such as the ACID properties of transactions, serializability, and various concurrency control protocols including lock-based and timestamp-based methods. Additionally, it covers failure classification, storage structures, and recovery mechanisms in database systems.

Uploaded by

japoxe5540
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
34 views7 pages

DBMS Unit 4 R22

The document outlines the syllabus for a DBMS course focusing on transaction management, concurrency control, and recoverability. It discusses key concepts such as the ACID properties of transactions, serializability, and various concurrency control protocols including lock-based and timestamp-based methods. Additionally, it covers failure classification, storage structures, and recovery mechanisms in database systems.

Uploaded by

japoxe5540
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

A19PC1CS04 UNIT - V DBMS

SYLLABUS
Transaction Management: Transaction state, Implementation of atomicity and Durability, Concurrent
executions – Serializability, Recoverability.
Concurrency Control: Lock Based Protocols, Timestamp Based Protocols, Validation Based Protocols,
Multiple Granularity, Dead Lock Handling
Recoverability: Failure Classification, Storage Structure, Recovery and Atomicity- Log Based recovery,
Recovery with concurrent transactions, Checkpoints.
Transaction Management
Introduction
• The term transaction refers to a collection of operations that form a single logical unit of work.
• A transaction is a unit of program execution that accesses and possibly updates various data items.
• A transaction is delimited by statements (or function calls) of the form begin transaction and end
transaction. The transaction consists of all operations executed between the begin transaction and end
transaction.
• Example: A bank employee transfers Rs 500 from A's account to B's account. This very simple and
small transaction involves several low-level tasks.
A’s Account
Open_Account(A)
Old_Balance = A.balance
New_Balance = Old_Balance - 500
A.balance = New_Balance
Close_Account(A)

B’s Account
Open_Account(B)
Old_Balance = B.balance
New_Balance = Old_Balance + 500
B.balance = New_Balance
Close_Account(B)

Properties of the transactions:


1. Atomicity: Either all operations of the transaction are reflected properly in the database, or none.
2. Consistency: Execution of a transaction in isolation (i.e., with no other transaction executing
concurrently) preserves the consistency of the database.
3. Isolation: Even though multiple transactions may execute concurrently, the system guarantees that,
for every pair of transactions Ti and Tj, it appears to Ti that either Tj finished execution before Ti
started or Tj started execution after Ti finished. Thus, each transaction is unaware of other transactions
executing concurrently in the system.
4. Durability: After a transaction completes successfully, the changes it has made to the database persist,
even if there are system failures.
• These properties are often called the ACID properties.
Operations of Transaction:
• Read(X): Read operation is used to read the value of X from the database and stores it in a buffer in
main memory.
• Write(X): Write operation is used to write the value back to the database from the buffer.
• Commit: It is used to save the work done permanently.
• Rollback: It is used to undo the work done.
1
A19PC1CS04 UNIT - V DBMS

1. SERIALIZABLE SCHEDULES:
• A non-serial schedule is called a serializable schedule if it can be converted to its equivalent serial
schedule.

i) Conflict Serializable
• A schedule is called conflict serializable if it can be transformed into a serial schedule by swapping
non-conflicting operations.
• The schedule will be a conflict serializable if it is conflict equivalent to a serial schedule.
• 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

Testing of Serializability:
• A Precedence Graph or Serialization Graph is used commonly to test the Conflict Serializability
of a schedule.
• It is a directed Graph (V, E) consisting of a set of nodes V = {T1, T2, T3…Tn} and a set of
directed edges E = {e1, e2, e3…em}.
• Steps to Construct a Precedence Graph
Step 1: Draw a node for each transaction in the schedule.
Step 2: For each pair of conflicting operations draw an edge
1. Create an edge Ti → Tj if Ti executes write (Q) before Tj executes read (Q).
2. Create an edge Ti → Tj if Ti executes read (Q) before Tj executes write (Q).
3. Create an edge Ti → Tj if Ti executes write (Q) before Tj executes write (Q).

Step 3: Check if the graph contains any cycles, then the schedule is not conflict serializable.
Otherwise, the schedule is conflict serializable.
Example 1:
T1 T2
R(A)
R(B) T T
W(A) 1 2
W(A)
R(B)

The graph is cyclic, we can conclude that it is not conflict serializable to any schedule serial schedule.

5
A19PC1CS04 UNIT - V DBMS

ii) View Serializable:


• A schedule is said to be View-Serializable if it is view-equivalent to a Serial Schedule.
• If a schedule is conflict serializable, then it will be view serializable.
• Two schedules are view-equivalent if they produce the same set of results when executed against
the same database state.
• Two schedules S1 and S2 are said to be view-equivalent if the below conditions are satisfied:
1. Initial Read: If a transaction T1 reads data item A from the database in S1 then in S2 also
T1 should read A from database.
2. Updated Read: If T1 is reading A which is updated by T2 in S1 then in S2 also T1 should
read A which is updated by T2.
3. Final Write: If a transaction T1 updated A at last in S1, then in S2 also T1 should perform
final write operations.
For Example:

Let’s check the S1 AND S2 are view-equivalent by applying three conditions


Initial Read
• In schedule S1, transaction T1 first reads the data item X. In S2 also transaction T1 first reads the
data item X.
• Let’s check for Y. In schedule S1, transaction T1 first reads the data item Y. In S2 also the first
read operation on Y is performed by T1.
• We checked for both data items X & Y and the initial read condition is satisfied in S1 & S2.
Final Write
• In schedule S1, the final write operation on X is done by transaction T2. In S2 also transaction T2
performs the final write on X.
• Let’s check for Y. In schedule S1, the final write operation on Y is done by transaction T2. In
schedule S2, final write on Y is done by T2.
• We checked for both data items X & Y and the final write condition is satisfied in S1 & S2.
Update Read
• In S1, transaction T2 reads the value of X, written by T1. In S2, the same transaction T2 reads the
X after it is written by T1.
• In S1, transaction T2 reads the value of Y, written by T1. In S2, the same transaction T2 reads the
value of Y after it is updated by T1.
• The update read condition is also satisfied for both the schedules.

Since all the three conditions and it satisfied in this example, S1 and S2 are view equivalent.

7
A19PC1CS04 UNIT - V DBMS

Checking Whether a Schedule is View Serializable or Not


Method-01:
• Check whether the given schedule is conflict serializable or not.
• If the given schedule is conflict serializable, then it is surely view serializable.
• If the given schedule is not conflict serializable, then it may or may not be view serializable.

Method-02:
• Check if there exists any blind write operation (Writing without reading is called as a blind write).
• If there is no blind write, then the schedule is not view serializable.
• If there exists any blind write, then the schedule may or may not be view serializable.

Method-03 (view equivalent method):


• In this method, try finding a view equivalent serial schedule (By using three conditions i.e., initial read,
updatable read and final write)
• Then, draw a graph using those dependencies.
• If there exists no cycle in the graph, then the schedule is view serializable otherwise not.

8
A19PC1CS04 UNIT - V DBMS

• Various lock-based protocols are:


a) Two-phase locking (2PL)
b) Strict 2PL
c) Rigorous 2PL
d) Conservative (Static) 2PL

a) Two-phase locking (2PL)


• A transaction is said to follow the Two-Phase Locking protocol if Locking and
Unlocking can be done in two phases.
• Growing Phase: New locks on data items may be acquired but none can be released.
• Shrinking Phase: Existing locks may be released but no new locks can be acquired.
• In 2PL, it does not look at whether it is committed or not.
• It lead to the problem are non-recoverable, starvation, deadlock and cascading schedule.

Example:
The following way shows how unlocking and
locking work with 2-PL.
Transaction T1:
• Growing phase: from step 1-3
• Shrinking phase: from step 5-7
• Lock point: at 3
Transaction T2:
o Growing phase: from step 2-6
o Shrinking phase: from step 8-9
o Lock point: at 6

In the above example, if lock conversion is allowed then the following phase can happen:
i. Upgrading of lock (from S(a) to X (a)) is allowed in growing phase.
ii. Downgrading of lock (from X(a) to S(a)) must be done in shrinking phase.
Note: Lock Point: The Point at which the growing phase ends.

b) Strict 2PL
• The first phase of Strict-2PL is similar to 2PL. In the first phase, after acquiring all the
locks, the transaction continues to execute normally.
• The only difference is it does not release a lock until commit X-locks will not release.
• Strict-2PL waits until the whole transaction to commit, and then it releases all the locks at
a time.
• Strict-2PL protocol does not have shrinking phase of lock release.
• A transaction can release a shared lock after the lock point, but it cannot release any
exclusive lock until the transaction commits.
13
A19PC1CS04 UNIT - V DBMS

• This protocol creates a cascade less schedule.

c) Rigorous 2PL
• A transaction cannot release any lock either shared or exclusive until it commits.
• Serializability is guaranteed in a Rigorous two-phase locking protocol.

d) Conservative (Static) 2PL


• acquires all locks before starting and releases all locks once done
• This protocol requires the transaction to lock all the items it accesses before the
Transaction begins execution by predeclaring its read-set and write-set.
• If any of the predeclared items needed cannot be locked, the transaction does not lock
any of the items, instead, it waits until all the items are available for locking.
• Conservative 2-PL is Deadlock free and but it does not ensure a Strict schedule.

2. Timestamp-based Protocols
• The most commonly used concurrency protocol is the timestamp-based protocol. This protocol
uses either system time or logical counter as a timestamp.
• Every transaction has a timestamp associated with it, and the ordering is determined by the age
of the transaction.
• A transaction created at 0002 clock time would be older than all other transactions that come
after it.
• For example, a transaction T1 is entering the system at 002 clock time is given priority then the
T2 transaction which entered at clock time 004.
• In addition, every data item is given the latest read and write-timestamp.
• This lets the system know when the last ‘read and write’ operation was performed on the data
item.
• The timestamp-ordering protocol ensures serializability among transactions in their conflicting
read and write operations.
• This is the responsibility of the protocol system that the conflicting pair of tasks should be
executed according to the timestamp values of the transactions.
• The timestamp of transaction Ti is denoted as TS(Ti).
• Read time-stamp of data-item X is denoted by R-TS(X).
• Write time-stamp of data-item X is denoted by W-TS(X).
• Whenever a Transaction T issues a W_item(X) operation, check the following conditions:
✓ If R_TS(X) > TS(T) or if W_TS(X) > TS(T), then abort and rollback the operation. Else
✓ Execute W_item(X) operation of T
• Whenever a Transaction T issues a R_item(X) operation, check the following conditions:
✓ If W_TS(X) > TS(T), then reject the operation, else
✓ If W_TS(X) <= TS(T), then execute the R_item(X) operation

14
A19PC1CS04 UNIT - V DBMS

Recoverability
Failure Classification
• Transaction failure:
– Logical errors: transaction cannot complete due to some internal condition such as bad input, data
not found
– System errors: the database system must terminate an active transaction due to an error condition
(e.g., deadlock)
• System crash: a power failure or other hardware or software failure causes the system to crash. (Ex:
operating system problem)
• Disk Transfer failure: a disk block loses its contents as a result of either a head crash or failure during
a data transfer operation.

Storage Structure
Volatile Memory
• These are the primary memory devices in the system, they can store only small amount of data, but they
are very fast.
• These memories cannot endure system crashes- data in these memories will be lost on failure.
• E.g.:- main memory, cache memory etc.

Non-Volatile memory
• These are secondary memories and are huge in size, but slow in processing.
• These memories are designed to withstand system crashes.
• E.g.: - Flash memory, hard disk, magnetic tapes etc.

Stable Memory
• This is said to be third form of memory structure but it is same as non-volatile memory. Here copies of
same non-volatile memories are stored at different places. This is because, in case of any crash and data
loss, data can be recovered from other copies.
• This is even helpful if there one of non-volatile memory is lost due to fire or flood. It can be recovered
from other network location.

19

You might also like