Transaction Management

and
Concurrency Control
 Transaction Concept
A Transaction is a unit of program execution that accesses and possibly updates various
data items.
• Transactions are initiated by a user program.
• A transaction is delimited by statements (or function calls) of the form Begin
transaction and End transaction.
• A transaction is indivisible i.e. it either executes entirely or not at all.
• This “all-or-none” property is referred as atomicity.
• If a transaction is not updating database but only retrieving data, it is referred as a
read-only transaction.
• A successful transaction can change the database from one Consistent state to another
 Transaction Concept
• Examples of transaction:
• Withdrawing cash from an ATM

Select
Insert Select the Select Enter PIN Select Collect
Begin ATM Card Language operation
Account
number Amount the cash End
type

• Changing password of a system

• Adding items in a cart while shopping online
• Booking a ticket
• Viewing your account balance
• Commenting on someone’s post
 Transaction Model
• Data items are identified by names.
• Transactions access data items using two operations:
• 𝑟𝑒𝑎𝑑 𝑋
• 𝑤𝑟𝑖𝑡𝑒(𝑋)

• Sample transaction of transferring 2000 ₹ From account 𝐴 to account 𝐵.

• Initially 𝐴 = 5000 ₹ and 𝐵 = 1200 ₹
𝑇𝑖 : 𝑟𝑒𝑎𝑑 𝐴 ;
A ≔ A − 2000;
𝑤𝑟𝑖𝑡𝑒 𝐴 ;
𝑟𝑒𝑎𝑑 𝐵 ;
B ≔ B + 2000;
𝑤𝑟𝑖𝑡𝑒 𝐵 .
 ACID Properties
ACID Properties are used for maintaining the integrity of database during transaction
processing.
• Atomicity: A transaction is a single unit of operation. You either execute it entirely or
do not execute it at all. There cannot be partial execution.
• Consistency: Once the transaction is executed, it should move from one consistent
state to another.
• Isolation: Transaction should be executed in isolation from other transactions. During
concurrent transaction execution, intermediate transaction results from
simultaneously executed transactions should not be made available to each other.
• Durability: · After successful completion of a transaction, the changes in the database
should persist. Even in the case of system failures.
 ACID Properties
• Consistency
• Sum of A and B to remain unchanged by the execution of transaction 𝑇𝑖 : 𝑟𝑒𝑎𝑑 𝐴 ;
A ≔ A − 2000;
• Atomicity
𝑤𝑟𝑖𝑡𝑒 𝐴 ;
• Withdrawal should be completed or not completed at all
𝑟𝑒𝑎𝑑 𝐵 ;
• Database system should keep track of old values of any data.
B ≔ B + 2000;
• In case of transaction failure, the database system restores the old value from 𝑤𝑟𝑖𝑡𝑒 𝐵 .
log

• Durability
• No system failure can result in a loss of data
• Once a transaction completes successfully, all the updates on database persist

• Isolation
• Execute transactions serially
 Transaction States
• Aborted Transaction
• The one which has not completed its execution successfully.
• Rolled Back Transaction
• When changes caused by aborted transaction are undone, the transaction is said to be
rolled back.
• Committed Transaction
• The one which completes its execution successfully.
• Compensating Transaction
• Which undoes the effect of a committed transaction.
 Transaction States
In a database, a transaction can be in one of the following states
• Active state
• Partially Committed state
• Committed state
• Failed state
• Aborted state
• Terminated state
 Transaction States

Read/Write Partially
Operations Committed
Committed Commit
(Permanent store)
Failure
Active Terminated

Failure Rollback
Failed Aborted

Fig. Transaction State Diagram

 Transaction Control Commands
• Transaction Control Language (TCL) is used to maintain the integrity and consistency of
the data stored in the database.
• A transaction starts when individual DML commands are executed
• The transaction gets committed when logical task is over.
• The commit command ensures that the changes are made permanent in the database.
• If the commit operation fails, the transaction gets rolled back and all the changes are
removed.
Transaction Control Commands

TCL
Commands

COMMIT ROLLBACK SAVEPOINT

 Transaction Control Commands
• BEGIN TRANSACTION
• It indicates the start point of an explicit or local transaction.
• Syntax:
𝑩𝑬𝑮𝑰𝑵 𝑻𝑹𝑨𝑵𝑺𝑨𝑪𝑻𝑰𝑶𝑵 𝒕𝒓𝒂𝒏𝒔𝒂𝒄𝒕𝒊𝒐𝒏_𝒏𝒂𝒎𝒆;
 Transaction Control Commands
• SET TRANSACTION
• Used to initiate a database transaction.
• This command is used to specify characteristics for the transaction that follows.
• We can specify a transaction to be read only or read write.
• Syntax:
𝑺𝑬𝑻 𝑻𝑹𝑨𝑵𝑺𝑨𝑪𝑻𝑰𝑶𝑵 [𝑹𝑬𝑨𝑫 𝑾𝑹𝑰𝑻𝑬|𝑹𝑬𝑨𝑫 𝑶𝑵𝑳𝒀]
• 𝑅𝐸𝐴𝐷 𝑊𝑅𝐼𝑇𝐸 Clause
• establish the current transaction as a read/write transaction. This clause establishes statement-level read
consistency, which is the default.
• 𝑅𝐸𝐴𝐷 𝑂𝑁𝐿𝑌 Clause
• Establishes the current transaction as a read-only transaction. This clause established transaction-level
read consistency
 Transaction Control Commands

Employee
EmpID EmpName EmpDept Manager Salary Address
101 Rashmi Comp Nilesh D. 35000 Virar
214 Omkar Sales Amit Bane 58000 Vasai
141 Brian Account Divya Singh 45500 Mumbai
212 Rina Extc Sanjay Sharma 50000 Satara
150 Jayesh Comp Nilesh D. 42000 Palghar
225 Minal Account Amit Bane 30000 Palghar
 Transaction Control Commands
• COMMIT
• Used to make a transaction permanent in a database.
• Saves the work done as it ends the current transaction by making permanent changes during
the transaction.
• Syntax:
𝑪𝑶𝑴𝑴𝑰𝑻;
• Example:
𝑼𝑷𝑫𝑨𝑻𝑬 𝑬𝒎𝒑𝒍𝒐𝒚𝒆𝒆 𝑺𝑬𝑻 𝑴𝒂𝒏𝒂𝒈𝒆𝒓 =′ 𝑺𝒂𝒏𝒋𝒂𝒚 𝑺𝒉𝒂𝒓𝒎𝒂′ 𝑾𝑯𝑬𝑹𝑬 𝑬𝒎𝒑𝑰𝑫 = 𝟐𝟐𝟓;
𝑪𝑶𝑴𝑴𝑰𝑻;
• The update transaction is completed with the commit command as above and statements will
update the manager of the employee having employee ID as 06.
• The change will be saved in the database permanently.
 Transaction Control Commands
• Result of Update followed by Commit operation
Employee
EmpID EmpName EmpDept Manager Salary Address
101 Rashmi Comp Nilesh D. 35000 Virar
214 Omkar Sales Amit Bane 58000 Vasai
141 Brian Account Divya Singh 45500 Mumbai
212 Rina Extc Sanjay Sharma 50000 Satara
150 Jayesh Comp Nilesh D. 42000 Palghar
225 Minal Account Sanjay
Amit Sharma
Bane 30000 Palghar
 Transaction Control Commands
• ROLLBACK
• Used to restore the database to its original state since the last command that was
committed.
• Syntax:
𝑹𝑶𝑳𝑳𝑩𝑨𝑪𝑲;
• The ROLLBACK command is used along with savepoint command to leap to a save point in a
transaction.
• Example:
𝑼𝑷𝑫𝑨𝑻𝑬 𝑬𝒎𝒑𝒍𝒐𝒚𝒆𝒆 𝑺𝑬𝑻 𝑴𝒂𝒏𝒂𝒈𝒆𝒓 =′ 𝑫𝒊𝒗𝒚𝒂 𝑺𝒊𝒏𝒈𝒉′ 𝑾𝑯𝑬𝑹𝑬 𝑬𝒎𝒑𝑰𝑫 = 𝟐𝟐𝟓;
𝑹𝑶𝑳𝑳𝑩𝑨𝑪𝑲;
• The update
 Transaction Control Commands
• Result of wrong Update operation
Employee
EmpID EmpName EmpDept Manager Salary Address
101 Rashmi Comp Nilesh D. 35000 Virar
214 Omkar Sales Amit Bane 58000 Vasai
141 Brian Account Divya Singh 45500 Mumbai
212 Rina Extc Sanjay Sharma 50000 Satara
150 Jayesh Comp Nilesh D. 42000 Palghar
225 Minal Account Sanjay
DivyaSharma
Singh 30000 Palghar
 Transaction Control Commands
• Result of wrong Update followed by Rollback operation
Employee
EmpID EmpName EmpDept Manager Salary Address
101 Rashmi Comp Nilesh D. 35000 Virar
214 Omkar Sales Amit Bane 58000 Vasai
141 Brian Account Divya Singh 45500 Mumbai
212 Rina Extc Sanjay Sharma 50000 Satara
150 Jayesh Comp Nilesh D. 42000 Palghar
225 Minal Account Sanjay
DivyaSharma
Singh 30000 Palghar
 Transaction Control Commands
• SAVEPOINT
• Used to save the transaction temporarily. So the users can rollback to the required point of
the transaction.
• Syntax:
𝑺𝑨𝑽𝑬𝑷𝑶𝑰𝑵𝑻 𝒔𝒂𝒗𝒆𝒑𝒐𝒊𝒏𝒕_𝒏𝒂𝒎𝒆;
• Example:
Order
OrderID ItemName Price
199 Television 25000
256 Camera 15000
301 Refrigerator 22570
108 Bottle 190
 Transaction Control Commands
• SAVEPOINT
• Example:
𝑰𝑵𝑺𝑬𝑹𝑻 𝑰𝑵𝑻𝑶 𝑶𝒓𝒅𝒆𝒓 𝑽𝑨𝑳𝑼𝑬𝑺 𝟑𝟐𝟐, ′Cell Phone′, 𝟏𝟓𝟗𝟗𝟗 ;
𝑪𝑶𝑴𝑴𝑰𝑻;
 Transaction Control Commands
• SAVEPOINT
• Example:
• The ORDERS table will be as below:
Order
OrderID ItemName Price
199 Television 25000
256 Camera 15000
301 Refrigerator 22570
108 Bottle 190
322 Cell Phone 15999
 Transaction Control Commands
• SAVEPOINT
• Example:
𝑰𝑵𝑺𝑬𝑹𝑻 𝑰𝑵𝑻𝑶 𝑶𝒓𝒅𝒆𝒓 𝑽𝑨𝑳𝑼𝑬𝑺 𝟑𝟐𝟐, ′Cell Phone′, 𝟏𝟓𝟗𝟗𝟗 ;
𝑪𝑶𝑴𝑴𝑰𝑻;
𝑼𝑷𝑫𝑨𝑻𝑬 𝑶𝒓𝒅𝒆𝒓 𝑺𝑬𝑻 𝑰𝒕𝒆𝒎𝑵𝒂𝒎𝒆 = ′Mobile Phone′ 𝑾𝑯𝑬𝑹𝑬 𝑶𝒓𝒅𝒆𝒓𝑰𝑫 = 𝟑𝟐𝟐;
𝑺𝑨𝑽𝑬𝑷𝑶𝑰𝑵𝑻 𝑨;
 Transaction Control Commands
• SAVEPOINT
• Example:
• The ORDERS table after update will be as below:
Order
OrderID ItemName Price
199 Television 25000
256 Camera 15000
301 Refrigerator 22570
108 Bottle 190
322 Mobile Phone 15999
 Transaction Control Commands
• SAVEPOINT
• Example:
𝑰𝑵𝑺𝑬𝑹𝑻 𝑰𝑵𝑻𝑶 𝑶𝒓𝒅𝒆𝒓 𝑽𝑨𝑳𝑼𝑬𝑺 𝟑𝟐𝟐, ′Cell Phone′, 𝟏𝟓𝟗𝟗𝟗 ;
𝑪𝑶𝑴𝑴𝑰𝑻;
𝑼𝑷𝑫𝑨𝑻𝑬 𝑶𝒓𝒅𝒆𝒓 𝑺𝑬𝑻 𝑰𝒕𝒆𝒎𝑵𝒂𝒎𝒆 = ′Mobile Phone′ 𝑾𝑯𝑬𝑹𝑬 𝑶𝒓𝒅𝒆𝒓𝑰𝑫 = 𝟑𝟐𝟐;
𝑺𝑨𝑽𝑬𝑷𝑶𝑰𝑵𝑻 𝑨;
𝑰𝑵𝑺𝑬𝑹𝑻 𝑰𝑵𝑻𝑶 𝑶𝒓𝒅𝒆𝒓 𝑽𝑨𝑳𝑼𝑬𝑺 𝟓𝟓𝟓, ′Blender′, 𝟖𝟓𝟎𝟎 ;
𝑺𝑨𝑽𝑬𝑷𝑶𝑰𝑵𝑻 𝑩;
 Transaction Control Commands
• SAVEPOINT
• Example:
• The ORDERS table after insert will be as below:
Order
OrderID ItemName Price
199 Television 25000
256 Camera 15000
301 Refrigerator 22570
108 Bottle 190
322 Mobile Phone 15999
555 Blender 8500
 Transaction Control Commands
• SAVEPOINT
• Example:
𝑰𝑵𝑺𝑬𝑹𝑻 𝑰𝑵𝑻𝑶 𝑶𝒓𝒅𝒆𝒓 𝑽𝑨𝑳𝑼𝑬𝑺 𝟑𝟐𝟐, ′Cell Phone′, 𝟏𝟓𝟗𝟗𝟗 ;
𝑪𝑶𝑴𝑴𝑰𝑻;
𝑼𝑷𝑫𝑨𝑻𝑬 𝑶𝒓𝒅𝒆𝒓 𝑺𝑬𝑻 𝑰𝒕𝒆𝒎𝑵𝒂𝒎𝒆 = ′Mobile Phone′ 𝑾𝑯𝑬𝑹𝑬 𝑶𝒓𝒅𝒆𝒓𝑰𝑫 = 𝟑𝟐𝟐;
𝑺𝑨𝑽𝑬𝑷𝑶𝑰𝑵𝑻 𝑨;
𝑰𝑵𝑺𝑬𝑹𝑻 𝑰𝑵𝑻𝑶 𝑶𝒓𝒅𝒆𝒓 𝑽𝑨𝑳𝑼𝑬𝑺 𝟓𝟓𝟓, ′Blender′, 𝟖𝟓𝟎𝟎 ;
𝑺𝑨𝑽𝑬𝑷𝑶𝑰𝑵𝑻 𝑩;
Use the SAVEPOINT command to Rollback the transaction.
𝑹𝑶𝑳𝑳𝑩𝑨𝑪𝑲 𝑻𝑶 𝑨;
 Transaction Control Commands
• SAVEPOINT
• Example:
• The ORDERS table will be as follows after ROLLBACK:
Order
OrderID ItemName Price
199 Television 25000
256 Camera 15000
301 Refrigerator 22570
108 Bottle 190
322 Mobile Phone 15999
 Transaction Control Commands
• RELEASE SAVEPOINT
• Used to remove a SAVEPOINT that you have created.
• Syntax:
𝑹𝑬𝑳𝑬𝑨𝑺𝑬 𝑺𝑨𝑽𝑬𝑷𝑶𝑰𝑵𝑻 𝒔𝒂𝒗𝒆𝒑𝒐𝒊𝒏𝒕_𝒏𝒂𝒎𝒆;
• Once a SAVEPOINT has been released, you can no longer use the ROLLBACK command to
undo transactions performed since the last SAVEPOINT.
 Concurrent Execution
• In a multi-user system, multiple users can access and use the same database at one
time, which is known as the concurrent execution of the database.
• The same database is executed simultaneously on a multi-user system by different
users.
• The simultaneous execution that is performed should be done in an interleaved
manner.
• No operation should affect the other executing operations, thus maintaining the
consistency of the database.
• Several problems may occur as a result of the concurrent execution of the transactions
 Concurrent Execution

Concurrency
Control
Problems

Lost Update Dirty Read Unrepeatable Phantom

Problem Problem Read Problem Read Problem
 Concurrent Execution
• Lost Update Problems (W-W Conflict)
• The problem occurs when two different database transactions perform the read/write
operations on the same database items in an interleaved manner (i.e., concurrent execution)
that makes the values of the data items incorrect hence making the database inconsistent.

Time 𝑻𝟏 𝑻𝟐
𝒕𝟏 𝑹𝑬𝑨𝑫(𝑨) --- Reads value of account A A=350
𝒕𝟐 𝑨 = 𝑨 − 𝟓𝟎 --- Deducts 50 Rs. From account A A=300
𝒕𝟑 --- 𝑹𝑬𝑨𝑫(𝑨) Reads value of account A A=350
𝒕𝟒 --- 𝑨 = 𝑨 + 𝟏𝟎𝟎 Adds 100 Rs. to account A A=450
𝒕𝟓 --- ---
𝒕𝟔 𝑾𝑹𝑰𝑻𝑬(𝑨) --- Writes the value of account A A=300
𝒕𝟕 --- 𝑾𝑹𝑰𝑻𝑬(𝑨) Writes the value of account A A=450
 Concurrent Execution
• Lost Update Problems (W-W Conflict)
• Transaction 𝑇2 overwrites the value of account 𝐴 written by transaction 𝑇1 .
• The value written by 𝑇1 is lost.
• Hence data becomes incorrect, and database sets to inconsistent.
 Concurrent Execution
• Dirty Read Problems (W-R Conflict)
• The dirty read problem occurs when one transaction updates an item of the database, and
somehow the transaction fails, and before the data gets rollback.
• The updated database item is accessed by another transaction.

Time 𝑻𝟏 𝑻𝟐
𝒕𝟏 𝑹𝑬𝑨𝑫(𝑨) --- Reads value of account A A=350
𝒕𝟐 𝑨 = 𝑨 + 𝟓𝟎 --- Adds 50 Rs. From account A A=400
𝒕𝟑 𝑾𝑹𝑰𝑻𝑬(𝑨) --- Writes the value of account A A=400
𝒕𝟒 --- 𝑹𝑬𝑨𝑫(𝑨) Reads value of account A A=400
𝒕𝟓 Server Down --- Rollback causes value of account A=350
Rollback A to get restored
 Concurrent Execution
• Dirty Read Problems (W-R Conflict)
• At time 𝑡5 , transaction 𝑇1 rollbacks due to server problem, and the value changes back to
350 rs. (as initially).
• The value for account 𝐴 remains 400 Rs. for transaction 𝑇2 as committed, which is the dirty
read.
• Therefore this problem is known as the Dirty Read Problem.
 Concurrent Execution
• Unrepeatable Read Problem (W-R Conflict)
• Also known as Inconsistent Retrievals Problem
• This problem occurs when in a transaction, two different values are read for the same
database item.
Time 𝑻𝟏 𝑻𝟐
𝒕𝟏 𝑹𝑬𝑨𝑫(𝑨) --- Reads value of account A A=350
𝒕𝟐 --- 𝑹𝑬𝑨𝑫(𝑨) Reads value of account A A=350

𝒕𝟑 --- 𝑨 = 𝑨 + 𝟏𝟎𝟎 Adds 100 Rs to the of account A A=450

𝒕𝟒 --- 𝑾𝑹𝑰𝑻𝑬(𝑨) Writes the value of account A A=450
𝒕𝟓 𝑹𝑬𝑨𝑫(𝑨) --- Reads value of account A A=450
 Concurrent Execution
• Unrepeatable Read Problem (W-R Conflict)
• Within the same transaction 𝑇1 , it reads two different values of account 𝐴, i.e., 350 Rs.
initially, and after updation made by transaction 𝑇2 , it reads 450 Rs.
• It is an unrepeatable read and is therefore known as the Unrepeatable read problem.

• Thus, in order to maintain consistency in the database and avoid such problems that
take place in concurrent execution, management is needed
 Concurrent Execution
• Phantom Read Problem
• The transaction reads a variable once and when it tries to read the variable again it gets an
error showing the variable does not exist, as the variable is deleted by another transaction.

Time 𝑻𝟏 𝑻𝟐
𝒕𝟏 𝑹𝑬𝑨𝑫(𝑨) --- Reads value of account A A=350
𝒕𝟐 --- 𝑹𝑬𝑨𝑫(𝑨) Reads value of account A A=350

𝒕𝟑 DELETE(A) --- Deletes the value of account A

𝒕𝟒 --- 𝑹𝑬𝑨𝑫(𝑨) Reads value of account A ERROR
 Concurrent Execution
• What is a Schedule?
• A series of operations from one or more transactions.
• Chronological order in which instructions are executed in the system.

• A schedule can be of two types:

• Serial Schedule
• When one transaction completely executes before starting another transaction.
• A serial schedule is always consistent.
• Concurrent Schedule
• When operations of a transaction are interleaved with operations of other transactions of a
schedule.
• Concurrency can lead to inconsistency in the database.
 Concurrent Execution
Schedule 1: Serial schedule 𝑇1 is followed by 𝑇2 Schedule 2: Serial schedule 𝑇2 is followed by 𝑇1
Initially 𝑻𝟏 𝑻𝟐 𝑻𝟏 𝑻𝟐
A=300 Rs.
𝑟𝑒𝑎𝑑 𝐴 𝑟𝑒𝑎𝑑 𝐴
B=500 Rs.
𝐴 ≔ 𝐴 − 50 𝑡𝑒𝑚𝑝 = 𝐴 ∗ 0.2
𝑤𝑟𝑖𝑡𝑒 𝐴 𝐴 ≔ 𝐴 − 𝑡𝑒𝑚𝑝
𝑟𝑒𝑎𝑑 𝐵 𝑤𝑟𝑖𝑡𝑒 𝐴
A+B need to be 𝐵 ≔ 𝐵 + 50 𝑟𝑒𝑎𝑑 𝐵
preserved 𝑤𝑟𝑖𝑡𝑒 𝐵 𝐵 ≔ 𝐵 + 𝑡𝑒𝑚𝑝
𝑐𝑜𝑚𝑚𝑖𝑡 𝑤𝑟𝑖𝑡𝑒 𝐵
𝑟𝑒𝑎𝑑 𝐴 𝑐𝑜𝑚𝑚𝑖𝑡
𝑡𝑒𝑚𝑝 = 𝐴 ∗ 0.2 𝑟𝑒𝑎𝑑 𝐴
𝐴 ≔ 𝐴 − 𝑡𝑒𝑚𝑝 𝐴 ≔ 𝐴 − 50
𝑤𝑟𝑖𝑡𝑒 𝐴 𝑤𝑟𝑖𝑡𝑒 𝐴
𝑟𝑒𝑎𝑑 𝐵 𝑟𝑒𝑎𝑑 𝐵
𝐵 ≔ 𝐵 + 𝑡𝑒𝑚𝑝 𝐵 ≔ 𝐵 + 50
𝑤𝑟𝑖𝑡𝑒 𝐵 𝑤𝑟𝑖𝑡𝑒 𝐵
𝑐𝑜𝑚𝑚𝑖𝑡 𝑐𝑜𝑚𝑚𝑖𝑡
 Concurrent Execution
Schedule 3: Concurrent schedule 𝑇1 is followed by 𝑇2 Schedule 4: Concurrent schedule 𝑇2 is followed by 𝑇1

𝑻𝟏 𝑻𝟐 𝑻𝟏 𝑻𝟐
𝑟𝑒𝑎𝑑 𝐴 𝑟𝑒𝑎𝑑 𝐴
Initially 𝐴 ≔ 𝐴 − 50 𝐴 ≔ 𝐴 − 50
A=300 Rs. 𝑤𝑟𝑖𝑡𝑒 𝐴 𝑟𝑒𝑎𝑑 𝐴
B=500 Rs. 𝑟𝑒𝑎𝑑 𝐴 𝑡𝑒𝑚𝑝 = 𝐴 ∗ 0.2
𝑡𝑒𝑚𝑝 = 𝐴 ∗ 0.2 𝐴 ≔ 𝐴 − 𝑡𝑒𝑚𝑝
𝐴 ≔ 𝐴 − 𝑡𝑒𝑚𝑝 𝑤𝑟𝑖𝑡𝑒 𝐴
𝑤𝑟𝑖𝑡𝑒 𝐴 𝑟𝑒𝑎𝑑 𝐵
𝑟𝑒𝑎𝑑 𝐵 𝑤𝑟𝑖𝑡𝑒 𝐴
𝐵 ≔ 𝐵 + 50 𝑟𝑒𝑎𝑑 𝐵
𝑤𝑟𝑖𝑡𝑒 𝐵 𝐵 ≔ 𝐵 + 50
𝑐𝑜𝑚𝑚𝑖𝑡 𝑤𝑟𝑖𝑡𝑒 𝐵
𝑟𝑒𝑎𝑑 𝐵 𝑐𝑜𝑚𝑚𝑖𝑡
𝐵 ≔ 𝐵 + 𝑡𝑒𝑚𝑝 𝐵 ≔ 𝐵 + 𝑡𝑒𝑚𝑝
𝑤𝑟𝑖𝑡𝑒 𝐵 𝑤𝑟𝑖𝑡𝑒 𝐵
𝑐𝑜𝑚𝑚𝑖𝑡 𝑐𝑜𝑚𝑚𝑖𝑡
 Concurrent Execution
• If the database system executes several transactions concurrently, then the schedule
no longer need to be serial.
• Context switch is performed to execute two or more transactions concurrently.
• When multiple transactions to execute concurrently, several execution sequences are
possible.
• Various instructions from multiple transactions may be interleaved.
• All concurrent executions may not result in correct state.
 Concurrent Execution
• Consistency of a database can be ensured under concurrent execution by making sure
that
Any schedule that is executed has the same effect as a schedule that could have
executed serially.

• i.e. the concurrent schedule should be equivalent to a serial schedule.

• Such schedules are called as serializable schedules.

 Serializability
• Serializability is the concept in a transaction that helps to identify which concurrent
schedule is correct and will maintain the database consistency.
• It relates to the isolation property of transaction in the database.
• It is the concurrency scheme where the execution of concurrent transactions is
equivalent to the transactions which execute serially.
• A serial schedule is always a serializable schedule.
• However, a concurrent schedule of transactions needs to be checked for Serializability.
If a schedule of concurrent 𝑛 transactions can be converted into an equivalent serial
schedule, then we can say that the schedule is serializable.
 Serializability
• Assume a schedule 𝑆 having two consecutive instructions 𝐴 and 𝐵, of transactions 𝑇𝑎
and 𝑇𝑏 respectively (𝑎 ≠ 𝑏).
• If 𝐴 and 𝐵 refer to same data item 𝑄, then order of execution of instructions may
matter.
• Four cases to consider:
1. 𝐴 = 𝑟𝑒𝑎𝑑 𝑄 , 𝐵 = 𝑟𝑒𝑎𝑑(𝑄) Order of 𝐴 and 𝐵 does not matter

2. 𝐴 = 𝑟𝑒𝑎𝑑 𝑄 , 𝐵 = 𝑤𝑟𝑖𝑡𝑒(𝑄) Order of 𝐴 and 𝐵 matters

3. 𝐴 = 𝑤𝑟𝑖𝑡𝑒 𝑄 , 𝐵 = 𝑟𝑒𝑎𝑑(𝑄) Order of 𝐴 and 𝐵 matters

4. 𝐴 = 𝑤𝑟𝑖𝑡𝑒 𝑄 , 𝐵 = 𝑤𝑟𝑖𝑡𝑒(𝑄) Order of 𝐴 and 𝐵 matters, it directly

affects the final value of 𝑄 in database
 Serializability
• Instructions 𝐴 and 𝐵 conflict if they are operations by different transactions on the
same data items, and at least one of these instructions is write instruction.
𝑻𝟏 𝑻𝟐 𝑻𝟏 𝑻𝟐
If instructions 𝐴 and 𝐵 do not
𝑟𝑒𝑎𝑑 𝑋 conflict, the order of 𝐴 and 𝐵 𝑟𝑒𝑎𝑑 𝑋
𝑤𝑟𝑖𝑡𝑒(𝑋) can be swapped to produce 𝑤𝑟𝑖𝑡𝑒(𝑋)
𝑟𝑒𝑎𝑑 𝑋 new schedule 𝑆 ′ . 𝑟𝑒𝑎𝑑 𝑋
𝑤𝑟𝑖𝑡𝑒(𝑋) 𝑆 is equivalent to 𝑆 ′ 𝑟𝑒𝑎𝑑 𝑌
𝑟𝑒𝑎𝑑 𝑌 𝑤𝑟𝑖𝑡𝑒(𝑋)
𝑤𝑟𝑖𝑡𝑒(𝑌) 𝑤𝑟𝑖𝑡𝑒(𝑌)
𝑟𝑒𝑎𝑑 𝑌 𝑟𝑒𝑎𝑑 𝑌
𝑤𝑟𝑖𝑡𝑒(𝑌) 𝑤𝑟𝑖𝑡𝑒(𝑌)
Schedule 5: Schedule 𝑺 Schedule 6: Schedule 𝑺′
 Serializability
• We can continue to swap non-conflicting instructions:

𝑻𝟏 𝑻𝟐 𝑻𝟏 𝑻𝟐 𝑻𝟏 𝑻𝟐 𝑻𝟏 𝑻𝟐
𝑟𝑒𝑎𝑑 𝑋 𝑟𝑒𝑎𝑑 𝑋 𝑟𝑒𝑎𝑑 𝑋 𝑟𝑒𝑎𝑑 𝑋
𝑤𝑟𝑖𝑡𝑒(𝑋) 𝑤𝑟𝑖𝑡𝑒(𝑋) 𝑤𝑟𝑖𝑡𝑒(𝑋) 𝑤𝑟𝑖𝑡𝑒(𝑋)
𝑟𝑒𝑎𝑑 𝑋 𝑟𝑒𝑎𝑑 𝑌 𝑟𝑒𝑎𝑑 𝑌 𝑟𝑒𝑎𝑑 𝑌
𝑟𝑒𝑎𝑑 𝑌 𝑟𝑒𝑎𝑑 𝑋 𝑟𝑒𝑎𝑑 𝑋 𝑤𝑟𝑖𝑡𝑒(𝑌)
𝑤𝑟𝑖𝑡𝑒(𝑋) 𝑤𝑟𝑖𝑡𝑒(𝑋) 𝑤𝑟𝑖𝑡𝑒(𝑌) 𝑟𝑒𝑎𝑑 𝑋
𝑤𝑟𝑖𝑡𝑒(𝑌) 𝑤𝑟𝑖𝑡𝑒(𝑌) 𝑤𝑟𝑖𝑡𝑒(𝑋) 𝑤𝑟𝑖𝑡𝑒(𝑋)
𝑟𝑒𝑎𝑑 𝑌 𝑟𝑒𝑎𝑑 𝑌 𝑟𝑒𝑎𝑑 𝑌 𝑟𝑒𝑎𝑑 𝑌
𝑤𝑟𝑖𝑡𝑒(𝑌) 𝑤𝑟𝑖𝑡𝑒(𝑌) 𝑤𝑟𝑖𝑡𝑒(𝑌) 𝑤𝑟𝑖𝑡𝑒(𝑌)

Schedule 𝑺′ Schedule 𝑺𝟏′ Schedule 𝑺𝟐′ Schedule 𝑺𝟑′

Serial Schedule equivalent to S
 Serializability
• If a schedule 𝑺 can be transformed into a schedule 𝑺′ by a series of swaps of non-
conflicting instructions, then 𝑺 and 𝑺′ are said to be conflict equivalent schedules.
• All serial schedules are conflict equivalent to each other.
• A schedule 𝑺 is a conflict serializable, if it is conflict equivalent to a serial schedule.
• Precedence Graph
• A graph consist of a pair 𝐺 = (𝑉, 𝐸), where 𝑉 is a set of vertices and 𝐸 is a set of edges.
• Vertices are transactions participating in schedule
• All edges 𝑇𝑖 → 𝑇𝑗 indicate
1. 𝑇𝑖 executes 𝑤𝑟𝑖𝑡𝑒(𝑄) before 𝑇𝑗 executes 𝑟𝑒𝑎𝑑(𝑄)
2. 𝑇𝑖 executes 𝑟𝑒𝑎𝑑(𝑄) before 𝑇𝑗 executes 𝑤𝑟𝑖𝑡𝑒(𝑄)
3. 𝑇𝑖 executes 𝑤𝑟𝑖𝑡𝑒(𝑄) before 𝑇𝑗 executes 𝑤𝑟𝑖𝑡𝑒(𝑄)
 Serializability
• Precedence Graph
• A graph consist of a pair 𝐺 = (𝑉, 𝐸), where 𝑉 is a set of vertices and 𝐸 is a set of edges.
• Vertices are transactions participating in schedule
• All edges 𝑇𝑖 → 𝑇𝑗 indicate
1. 𝑇𝑖 executes 𝑤𝑟𝑖𝑡𝑒(𝑄) before 𝑇𝑗 executes 𝑟𝑒𝑎𝑑(𝑄)
2. 𝑇𝑖 executes 𝑟𝑒𝑎𝑑(𝑄) before 𝑇𝑗 executes 𝑤𝑟𝑖𝑡𝑒(𝑄)
3. 𝑇𝑖 executes 𝑤𝑟𝑖𝑡𝑒(𝑄) before 𝑇𝑗 executes 𝑤𝑟𝑖𝑡𝑒(𝑄)
• If an edge 𝑇𝑖 → 𝑇𝑗 exists in the precedence graph, then in any serial schedule 𝑺′ equivalent
to 𝑺, 𝑇𝑖 must appear before 𝑇𝑗
 Serializability
• Precedence Graph
𝑻𝟏 𝑻𝟐 𝑻𝟏 𝑻𝟐
𝑟𝑒𝑎𝑑 𝐴 𝑟𝑒𝑎𝑑 𝐴
𝑤𝑟𝑖𝑡𝑒 𝐴 𝑤𝑟𝑖𝑡𝑒 𝐴
𝑟𝑒𝑎𝑑 𝐵 𝑻𝟏 𝑻𝟐 𝑟𝑒𝑎𝑑 𝐵 𝑻𝟐 𝑻𝟏
𝑤𝑟𝑖𝑡𝑒 𝐵 𝑤𝑟𝑖𝑡𝑒 𝐵
𝑟𝑒𝑎𝑑 𝐴 𝑟𝑒𝑎𝑑 𝐴
𝑤𝑟𝑖𝑡𝑒 𝐴 Precedence graph for 𝑤𝑟𝑖𝑡𝑒 𝐴 Precedence graph for
𝑟𝑒𝑎𝑑 𝐵 schedule 1 𝑟𝑒𝑎𝑑 𝐵 schedule 2
𝑤𝑟𝑖𝑡𝑒 𝐵 𝑤𝑟𝑖𝑡𝑒 𝐵
Schedule 1 Schedule 2
(only read write operations) (only read write operations)
 Serializability
• Precedence Graph
𝑻𝟏 𝑻𝟐 • If the precedence graph for 𝑺 has a cycle, then
the schedule 𝑺 is not conflict serializable.
𝑟𝑒𝑎𝑑 𝐴
𝑟𝑒𝑎𝑑 𝐴
𝑤𝑟𝑖𝑡𝑒 𝐴 • If the precedence graph contains no cycle, then
𝑟𝑒𝑎𝑑 𝐵 𝑻𝟏 𝑻𝟐 the schedule 𝑺 is conflict serializable.
𝑤𝑟𝑖𝑡𝑒 𝐴
𝑟𝑒𝑎𝑑 𝐵
𝑤𝑟𝑖𝑡𝑒 𝐵 Precedence graph
𝑤𝑟𝑖𝑡𝑒 𝐵 for schedule 4
Schedule 4
(only read write operations)
• Absent Nos.
5, 9, 11, 17, 29, 30, 31, 44, 45, 49, 52, 53, 55, 56, 58, 60, 61, 62, 64, 65, 67, 68
Total Absent 22
 Serializability
• Precedence Graph
• Serializability order of the transaction can be obtained by finding a linear order consistent
with the partial order of the precedence graph and this process is known as topological
sorting.
𝑻𝒊 𝑻𝒊
𝑻𝒊

𝑻𝒋 𝑻𝒌
𝑻𝒋 𝑻𝒌

𝑻𝒎 𝑻𝒌 𝑻𝒋

𝑻𝒎 𝑻𝒎
 Serializability
• View Serializability
• A schedule will 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 𝑆1 and 𝑆2 are view equivalent if they satisfy following conditions:
• Initial Read:
An initial read of both schedules must be the same.
• Update read:
In schedule 𝑆1 , if 𝑇𝑖 is reading 𝐴 which is updated by 𝑇𝑗 then in 𝑆2 also, 𝑇𝑖 should read A which is
updated by 𝑇𝑗 .
• Final Write:
A final write must be the same between both the schedules.
 Serializability
• View Serializability
𝑻𝟏 𝑻𝟐 𝑻𝟑 3! = 6 possible execution sequences
𝑟𝑒𝑎𝑑 𝐴
𝑤𝑟𝑖𝑡𝑒(𝐴) 𝑆1 = 𝑇1 → 𝑇2 → 𝑇3 𝑆3 = 𝑇2 → 𝑇1 → 𝑇3 𝑆5 = 𝑇3 → 𝑇1 → 𝑇2
𝑤𝑟𝑖𝑡𝑒(𝐴)
𝑆2 = 𝑇1 → 𝑇3 → 𝑇2 𝑆4 = 𝑇2 → 𝑇3 → 𝑇1 𝑆6 = 𝑇3 → 𝑇2 → 𝑇1
𝑤𝑟𝑖𝑡𝑒(𝐴)
𝑺𝒄𝒉𝒆𝒅𝒖𝒍𝒆 𝑺

𝑻𝟏 𝑻𝟐 𝑻𝟑 𝑻𝟏 𝑻𝟐 𝑻𝟑
𝑟𝑒𝑎𝑑 𝐴 𝑤𝑟𝑖𝑡𝑒(𝐴)
𝑤𝑟𝑖𝑡𝑒(𝐴) 𝑤𝑟𝑖𝑡𝑒(𝐴)
𝑤𝑟𝑖𝑡𝑒(𝐴) 𝑟𝑒𝑎𝑑 𝐴
𝑤𝑟𝑖𝑡𝑒(𝐴) 𝑤𝑟𝑖𝑡𝑒(𝐴)
𝑆 and 𝑆1 are View Equivalent 𝑆 and 𝑆4 are not View Equivalent
 Concurrency Control
Concurrency Control is a procedure of managing simultaneous operations without
conflicting with each other.
• It ensures that database transactions are performed concurrently and accurately to
produce correct results without violating data integrity of the respective database.
• Why Concurrency Control Methods?
• To apply Isolation through mutual exclusion between conflicting transactions
• To resolve read-write and write-write conflict issues
• To preserve database consistency through constantly preserving execution obstructions
• To control the interaction among the concurrent transactions
• Concurrency control helps to ensure serializability.
 Concurrency Control
• Concurrency Control Protocols
• To avoid concurrency control problems and to maintain consistency and serializability during
the execution of concurrent transactions some rules are made.

Concurrency
Control
Protocols

Time-stamped Validation
Lock based
based based
Protocols
Protocols Protocols
 Concurrency Control
• Lock Based Protocols
• To attain consistency, isolation between the transactions is the most important tool.
• Isolation is achieved if we disable the transaction to perform a read/write operation.
• Through lock-based protocols, desired operations are freely allowed to perform locking the
undesired operations.
• Two kinds of locks used in lock-based protocols
• Shared Lock 𝑺
• The locks which disable the write operations but allow read operations for any data in a
transaction are known as shared locks.
• Exclusive Lock (𝑿)
• The locks which disable both the write and read operations for any data in a transaction are
known as exclusive locks.
 Concurrency Control
• Lock Based Protocols
• Lock compatibility 𝑇𝑗
Shared Exclusive
Lock Lock
Shared
True False
Lock
𝑇𝑖
Exclusive
False False
Lock

• If transaction 𝑇𝑖 can be granted a lock 𝐴 on data item 𝑄 immediately, in spite of the presence
of the mode 𝐵 lock held by transaction 𝑇𝑗 , then we say mode 𝐴 is compatible with mode 𝐵 .
 Concurrency Control
• Lock Based Protocols
• Lock compatibility

Transaction 𝑻𝟐

Transaction 𝑻𝟏
Concurrency Control
• Lock Based Protocols
• Lock compatibility
 Concurrency Control
• Lock Based Protocols
• Lock compatibility

Transaction 𝑻𝟒
(Transaction 𝑻𝟐 with
delayed unlocking)
Transaction 𝑻𝟑
(Transaction 𝑻𝟏 with
delayed unlocking)
 Concurrency Control
• Lock Based Protocols
• Locking can lead to an undesirable situation.
• DEADLOCK
• When deadlock occurs, the system must roll back one of the
two transactions
 Concurrency Control
• Lock Based Protocols
• Four kinds of lock-based protocols
• Simplistic Lock Protocol
• Instructs to lock all the other operations on the data when the data is going to get updated.
• All the transactions may unlock all the operations on the data after the write operation.

• Pre-claiming Lock Protocol

• An assessment of the operations that are going to be performed is conducted.
• Then a list is prepared to contain the data items on which locks will be imposed.
• The transaction requests the system all the locks before starting the execution of the
operations.
• If all the locks are provided then the operations in the transaction run smoothly and then locks
are returned to the system on completion.
• The transaction rolls back if all the locks are not provided.
 Concurrency Control
• Lock Based Protocols
• Two-Phase locking (2PL) Protocol
• Consists of three phases.
• The transaction starts its execution with the first phase, where it asks for the locks.
• Once the locks are granted, the second phase begins, where the transaction contains all the
locks.
• When the transaction releases the first lock, the third phase begins where all the locks are
getting released after the execution of every operation in the transaction.
• Allows each transaction to make a lock or unlock request in two steps:
• Growing Phase: a transaction may obtain locks but may not release any locks.
• Shrinking Phase: a transaction may release locks but not obtain any new lock.
 Concurrency Control
• Lock Based Protocols
• Two-Phase locking (2PL) Protocol
 Concurrency Control
• Lock Based Protocols
• Strict Two-Phase locking (2PL) Protocol
• Similar to 2PL.
• The only difference is that the strict 2PL does not allow releasing the locks just after the
execution of the operations, but it carries all the locks and releases them when the commit is
triggered.
 Concurrency Control
• Lock Based Protocols
• When a transaction 𝑇𝑖 issues a 𝑟𝑒𝑎𝑑(𝑄) operation, the system issues a 𝑙𝑜𝑐𝑘 − 𝑆(𝑄)
instruction followed by the 𝑟𝑒𝑎𝑑(𝑄) instruction.
• When 𝑇𝑖 issues a 𝑤𝑟𝑖𝑡𝑒(𝑄) operation, the system checks to see whether 𝑇𝑖 already holds a
shared lock on 𝑄
• If it does, then the system issues an 𝑢𝑝𝑔𝑟𝑎𝑑𝑒(𝑄) instruction, followed by the 𝑤𝑟𝑖𝑡𝑒(𝑄)
instruction.
• Otherwise, the system issues a 𝑙𝑜𝑐𝑘 − 𝑋(𝑄) instruction, followed by the 𝑤𝑟𝑖𝑡𝑒(𝑄) instruction.

• All locks obtained by a transaction are unlocked after that transaction commits or aborts.
 Concurrency Control
• Time-stamp Based Protocols
Every transaction has a timestamp attached to it.
• The timestamp is based on the time in which the transaction is entered into the system.
• There is read and write timestamps associated with every transaction which consists of the
time at which the latest read and write operations are performed respectively.
• Timestamp Ordering Protocol:
• Uses timestamp values of the transactions to resolve the conflicting pairs of operations.

Term Denotations
Timestamp of transaction A 𝑇𝑆(𝐴)
Read timestamp of data item D 𝑅 − 𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝(𝐷)
Write timestamp of data item D 𝑊 − 𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝(𝐷)
 Concurrency Control
• Time-stamp Based Protocols
• Timestamp Ordering Protocol:
Rules on which the Time-ordering protocol works:
• When transaction A is going to perform a read operation on data item D:
• If 𝑇𝑆 𝐴 < 𝑊 − 𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 𝐷 , transaction will roll back
• If 𝑇𝑆 𝐴 ≥ 𝑊 − 𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 𝐷 , transaction will be executed
• All data timestamps are updated
• When transaction A is going to perform a write operation on data item D:
• If 𝑇𝑆 𝐴 < 𝑅 − 𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 𝐷 , transaction will roll back
• If 𝑇𝑆 𝐴 < 𝑊 − 𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 𝐷 , transaction will rollback
• All the operations other than this will be executed.
 Concurrency Control
• Time-stamp Based Protocols
• Timestamp Ordering Protocol:
Rules on which the Time-ordering protocol works:
• When transaction A is going to perform a read operation on data item D:
• If 𝑇𝑆 𝐴 < 𝑊 − 𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 𝐷 , transaction will roll back
• If 𝑇𝑆 𝐴 ≥ 𝑊 − 𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 𝐷 , transaction will be executed
• All data timestamps are updated
• When transaction A is going to perform a write operation on data item D:
• If 𝑇𝑆 𝐴 < 𝑅 − 𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 𝐷 , transaction will roll back
• If 𝑇𝑆 𝐴 < 𝑊 − 𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 𝐷 , transaction will rollback
• All the operations other than this will be executed.
• Absent nos.
• 5, 8, 12, 17, 21, 28, 29, 46, 49, 58,
 Deadlock Handling
• A system is in a deadlock state if there exists a set of transactions such that every
transaction in the set is waiting for another transaction in the set.
• Two principal methods for dealing with the deadlock
• Deadlock Prevention Protocol
• Ensures that the system will never enter a deadlock state.
• Deadlock Detection and Deadlock Recovery Protocol
• Allow the system to enter a deadlock state, and then try to recover from it.
 Deadlock Handling
• Deadlock Prevention Protocol
• Ensures that no cyclic waits can occur by ordering the requests for locks
Or
• All locks need to be acquired together before starting execution.
• Another approach for preventing deadlocks is to use preemption and transaction rollbacks.
• To control the preemption, we assign a unique timestamp.
• The system uses these timestamps only to decide whether a transaction should wait or roll
back
• A wait-die Scheme (non preemptive)
• A wound-wait Scheme (Preemptive)
 Deadlock Handling
• Deadlock Detection and Recovery Protocol
• An algorithm that examines the state of the system is invoked periodically to determine
whether a deadlock has occurred.
• The system must:
• Maintain information about the current allocation of data items to transactions, as well as
any outstanding data item requests.
• Provide an algorithm that uses this information to determine whether the system has
entered a deadlock state.
• Recover from the deadlock when the detection algorithm determines that a deadlock
exists.
 Deadlock Handling
• Deadlock Detection and Recovery Protocol
• Deadlock Detection
• Deadlocks can be described precisely in terms of a directed
graph called a wait-for graph.
• A directed edge from transaction 𝑇𝑖 to 𝑇𝑗 , implying that
transaction 𝑇𝑖 is waiting for transaction 𝑇𝑗 to release a data
item that it needs.
• A deadlock exists in the system if and only if the wait-for
graph contains a cycle.
• To detect deadlocks, the system needs to maintain the wait-
for graph, and periodically to invoke an algorithm that
searches for a cycle in the graph.
 Deadlock Handling
• Deadlock Detection and Recovery Protocol
• Recovery from Deadlock
• When a detection algorithm determines that a deadlock exists, the system must recover from the
deadlock.
• Three actions need to be taken
• Selection of victim
• Determine which transaction (or transactions) to roll back to break the deadlock.
• Rollback
• Determine how far this transaction should be rolled back.
• Total rollback
• Partial rollback
• Starvation
• Ensure that a transaction can be picked as a victim only a (small) finite number of times.
 Recovery System
• A recovery scheme that can restore the database to the consistent state that existed
before the failure.
• The recovery scheme must also provide high availability.

Logical error
Transaction
failure
System error
Failure
System crash
Classification

Disk failure
 Recovery System
• Goal is to perform either all or no database modifications made by transactions.
• To achieve the goal of atomicity, it is necessary to get a stable storage information
describing the modifications.
• Log records
• The log is a sequence of log records, recording all the update activities in the database.
• An update log record describes a single database write. It has following fields:
• Transaction Identifier
• Data item identifier
• Old value
• New value
< 𝑻𝒊 , 𝑿𝒋 , 𝑽𝟏 , 𝑽𝟐 >
 Recovery System
• Log records
• Other type of log records are
• < 𝑻𝒊 𝒔𝒕𝒂𝒓𝒕 >
• < 𝑻𝒊 𝒄𝒐𝒎𝒎𝒊𝒕 >
• < 𝑻𝒊 𝒂𝒃𝒐𝒓𝒕 >

• Database Modifications
• A transaction modifies the database if it performs an update on a disk buffer, or on the disk
itself.
• If a transaction does not modify the database until it has committed, it is said to use the
deferred-modification technique.
• If database modifications occur while the transaction is still active, the transaction is said to
use the immediate-modification technique.
 Recovery System
• Database Modifications
• All database modifications must be preceded by the creation of a log record.
• The system has available both the old value prior to the modification of the data item and
the new value that is to be written for the data item.
• This allows the system to perform undo and redo operations as appropriate.