CE4031/CZ4031

DATABASE
SYSTEM PRINCIPLES
TRANSACTION MANAGEMENT
BACKGROUND

So far

• Basic access primitive is considered a query.

• Retrieve-only (or read-only) query.
• Queries that read data from the database.

What happens?
• When two queries attempt to update the same data
item?
• System fails during query execution?
RETRIEVE-ONLY QUERIES

Is it a problem? No!

Why?

• Two queries can read the same data item concurrently.

• A read-only query can simply restart after failure is
handled.

How about update queries?

• Disastrous!
• Simply can’t restart as certain data values may already
have been updated prior to the failure.
MOTIVATION
Durability
• You transferred $1,000 between bank accounts but there
is a power failure.
• Recovery

Lost Updates

• We both change the same record in a table at the same

time.
• Concurrency control

Concurrency Control & Recovery

• Valuable properties of database management systems
(DBMS).
• Based on the concept of transactions with ACID properties.
ISSUE 1

ONE-PASS ALGORITHMS

What is a transaction?
TRANSACTION

What is it?

• The processes that query and modify the database.

• Like any program, executes a number of steps in
sequence.
• Several of these steps may modify the database.
• Basic unit of change in a DBMS.
• Partial transactions are not allowed!

Example
Move $1,000 from Freddy’s account to his bookie’s account.

Transaction
• Check whether Freddy has $1,000.
• Deduct $1,000 from his account.
• Add $1,000 to his bookie’s account.
 STRAWMAN APPROACH

Serial Order Execution

• Execute each transaction one-by-one (i.e., serial order) as

they arrive at the DBMS.
• Only one transaction can run in the DBMS at a time.
STRAWMAN APPROACH
STRAWMAN APPROACH

Handling failures
• Before a transaction starts, copy the entire database to a
new file and make all changes to that file.
• If the transaction completes successfully, overwrite the
original file with the new one.
• If the transaction fails, just remove the dirty copy.
CAN DO BETTER!

Better approach

• Allow concurrent execution of independent

transactions.

Wash multiple vehicles

CAN DO BETTER!

Why do we want that?

• Utilisation/ throughput
• Increased response times to users.

But we also would like..

• Correctness
• Fairness
• Hard problems!
DEFINITION OF A TRANSACTION
Conceptually

• A transaction takes a database as an input.

• Performs an action on it.
• Generates a new version of the database.

Consists of?
• A sequence of read and write operations on the database,
together with computation steps.
TRANSACTIONS IN SQL
Start of a transaction

• A new transaction starts with the BEGIN command.

End of transaction
• A transaction stops with either COMMIT or ABORT.
• If commit, all changes are saved.
• If abort, all changes are undone so that it’s like as if the
transaction never executed at all.
• Abort can be either self-inflicted or caused by the DBMS.
EXAMPLE

FLIGHT(FNO, DATE, SRC, DEST, STSOLD, CAP)

CUST(CNAME, ADDR, BAL) • Delimits the
FC(FNO, DATE, CNAME, SPECIAL) transactions.
• If not specified, then
Begin transaction Reservation DBMS treats as a
begin transaction the entire
input(flight_no, date, customer name); program that performs
EXEC SQL UPDATE FLIGHT
a database access.
SET STSOLD = STSOLD + 1
WHERE FNO = flight no
AND DATE = date;
EXEC SQL INSERT
INTO FC(FNO, DATE, CNAME, SPECIAL)
VALUES(flight_no, date, customer name, null);
Commit;
output(“reservation completed”)
end
 EXAMPLE
Begin transaction Reservation
begin
input(flight_no, date, customer name);
EXEC SQL SELECT STSOLD, CAP INTO temp1, temp2
FROM FLIGHT
WHERE FNO = flight_no AND DATE = date;
if temp1 = temp2 then
begin
output(“no free seats”); Due to
Abort
end application logic.
else begin
EXEC SQL UPDATE FLIGHT
SET STSOLD = STSOLD + 1
WHERE FNO = flight_no AND DATE = date;
EXEC SQL INSERT
INTO FC(FNO,DATE,CNAME,SPECIAL)
VALUES(flight_no, date, customer name, null);
Commit;
output(“reservation completed”)
end
end-if
end
ISSUE 2

ONE-PASS ALGORITHMS

What properties must a transaction satisfy?

TRANSACTIONS PROPERTIES

Atomicity
A transaction is either performed in its entirety (can be in
steps) or not performed at all.

Consistency
If T starts with database in consistent state +
T executes in isolation ⇒ T leaves consistent state

Isolation
A transaction should appear as though it is executed in
isolation from other transactions.

Durability
Changes applied to the database by a committed transaction
must persist in the database.
 ATOMICITY OF TRANSACTIONS

Two possible outcomes of executing a

transaction

• Commit after completing all its actions.

• Abort (or be aborted by the DBMS) after
executing some actions.

DBMS guarantee

• DBMS guarantees that transactions are

atomic.
• From user’s point of view, transactions
always either executes all of its actions, or
executes no actions at all.
MECHANISM OF ENSURING ATOMICITY
Logging
• DBMS logs all actions so that it can undo the actions
of aborted transactions.
• Used by all modern DBMS.
• Audit trails and efficiency reasons.

Shadow paging

• DBMS makes copies of pages and transactions make

changes to those copies.
• Only when the transaction commits, the page is made
visible to others.
• Originally from System R.
• Used by CouchDB.
CONSISTENCY

Consistency

• The "world" represented by the database is logically

correct.
• All questions asked about the data are given logically
correct answers.

Two types
• Database consistency
• Transaction consistency
 DATABASE CONSISTENCY

State of a database
• State changes occur due to updates
• Modifications
• Insertions
• Deletions

Consistent State

• A database is in consistent state if it obeys all of the

consistency (integrity) constraints defined over it.
• Database should be consistent when the transaction
terminates.
DATABASE CONSISTENCY

Database in a Database may be temporarily Database in a

consistent in an inconsistent state during consistent
state execution state

Execution of Transaction T

Begin End
Transaction T Transaction T
TRANSACTION CONSISTENCY
What is it?
• Actions of concurrent transactions.
• Database should be in consistent state even if there are a
number of user requests that are concurrently accessing
(reading or updating) the database.

Database in a Database in a
consistent consistent
state state
ISOLATION OF TRANSACTION

Isolation
• Users submit transactions, and each transaction
executes as if it was running by itself.
• Appear as though it is executed in isolation from
other transactions.

Implications
An executing transaction cannot reveal its results to other
concurrent transactions before its commitment.

Concurrency

• Concurrency is achieved by DBMS, which interleaves

actions (reads/ writes) of various transactions.
MECHANISM FOR ENSURING ISOLATION

Protocol

• A concurrency control protocol is how the DBMS

decides the proper interleaving of operations from
multiple transactions.

Two categories of protocol

• Pessimistic: Don’t let problems arise in the first place.

• Optimistic: Assume conflicts are rare, deal with them
when they happen.
TRANSACTION DURABILITY

Durable changes

• All of the changes of committed transactions should

be persistent.
• No torn updates.
• No changes from failed transactions.

How it is enforced?

The DBMS can use either logging or shadow paging to

ensure that all changes are durable.
ISSUE 3

ONE-PASS ALGORITHMS

How do we abstract a transaction as a

set of operation?
PRELIMINARIES

Assumption 1

• Database composed of elements

• Usually 1 element = 1 block.
• Can be smaller (=1 record) or larger (=1 relation).

Assumption 2

• Each transaction reads/ writes some elements.

PRELIMINARIES

State of a transaction

• Each transaction has a state.

• Represents what has happened so far in the transaction.
• Current place in the transaction’s code being
executed.
• Values of the local variables.

Database state

• A value for each of its elements.

• Consistent state
• Satisfy all constraints of the database schema.
• Consistent database
• Database in consistent state.
 PRIMITIVE OPERATIONS OF TRANSACTIONS

Operation Semantics
START TRANSACTION
READ(X, t) Copy database
element X to
READ(A,t);
transaction’s local t := t*2;
variable t WRITE(A,t);
WRITE(X, t) copy transaction READ(B,t);
local variable t to t := t*2;
element X
WRITE(B,t);
INPUT(X) read element X to
COMMIT;
memory buffer

OUTPUT(X) write element X to

disk
MOTIVATION

Action t Mem A Mem B Disk A Disk B Database in

READ(A,t)
8 8 8 8 inconsistent state!!
t := t*2 16 8 8 8 (loses atomicity)
WRITE(A, t)
16 16 8 8
READ(B, t)
8 16 8 8 8
t := t*2
16 16 8 8 8
WRITE(B, t)
16 16 16 8 8
OUTPUT(A) 16 16 16 16 8
OUTPUT(B) 16 16 16 16 16
CONCLUSION

ONE-PASS ALGORITHMS
Transaction management
Deal with the problems of always keeping the database in a consistent
state even when concurrent accesses and failures occur.

Definition and Properties of Transactions

Operations in Transactions