Distributed Database Systems Introduction to Transaction Management (Ozsu Chap. 10.1, 10.2 & 10.

4)
605.741 David Silberberg

Introduction
Up until now, we have concentrated on query management
Planning Optimization Execution

However, we need to make the distributed database system more robust

Failures (e.g., site crashes) Conflicts (e.g., two queries simultaneously updating the database)

We want consistent execution and reliable computation Transactions provides both consistency and reliability
D. Silberberg Distributed Database Systems Introduction to Transaction Mgmt. 2

Transaction Management Definitions

Database consistency
Obeys integrity checks
Foreign keys Cascading deletes, if specified

Database is usually inconsistent during an operation, but consistent before and after

Transaction consistency
Allow multiple queries to update database, yet maintain consistency When the database is distributed
We want mutual consistency to ensure all copied data is identical Referred to as one-copy equivalence

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

More Definitions
Reliability
Resiliency to failures Ability to recover from failures

Transaction management
Deals with the problem of keeping database(s) in a consistent state Consistency must be maintained even with failures

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

Transactions in Java Code

BEGIN Transaction and END Transaction statements: { Connection conn = DriverManager.getConnection("URL", properites); conn.setAutoCommit(false); // Begin transaction Statement stmt = conn.createStatement(); stmt.executeUpdate("UPDATE PART SET parts_sold = parts_sold + 1 WHERE pno = 153"); conn.commit(); // End transaction }
D. Silberberg Distributed Database Systems Introduction to Transaction Mgmt. 5

Example Database Schema

PART(pno, part_name, parts_sold, total_parts) STORE(sno, store-name, address, balance) ORDER(pno, sno, special)

PART

ORDER

STORE

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

Sample Transaction

{ Connection conn = DriverManager.getConnection("URL", properites); conn.setAutoCommit(false); // begin transaction Statement stmt = conn.createStatement(); stmt.executeUpdate("UPDATE PART SET parts_sold = parts_sold + 1 WHERE pno = 153"); stmt = conn.createStatement(); stmt.executeUpdate("INSERT INTO ORDER VALUES(153, 11, "deliver"); conn.commit(); // end transaction System.out.println("Order processed!"); }

Someone places an order

Orders table gets updated Parts table gets updated

Both updates or neither must be executed In this example, we assume that the transaction completes

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

More Realistic Example

Use ABORT and COMMIT statements
Defines what to do in both situations Either accepts all or rolls back all { Connection conn = DriverManager.getConnection("URL", properites); conn.setAutoCommit(false); // Initiate transaction Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery ("SELECT parts_sold, total_parts FROM PART WHERE pno = 153");

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

Realistic Example ABORT Condition

if (rs.next()) // if used because there is at most one matching record { partsSold = rs.getInt("parts_sold"); totalParts = rs.getInt("total_parts "); } if (parts_sold == total_parts) { System.out.println("parts sold out") // must be before ABORT conn.rollback(); // ABORT with database recovery }

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

Realistic Example COMMIT Condition

else { Statement stmt = conn.createStatement(); stmt.executeUpdate("UPDATE PART SET parts_sold = parts_sold + 1 WHERE pno = 153"); stmt = conn.createStatement(); stmt.executeUpdate("INSERT INTO ORDER VALUES(153, 11, "deliver"); conn.commit(); // COMMIT System.out.println("Order processed!") // after COMMIT } }
D. Silberberg Distributed Database Systems Introduction to Transaction Mgmt. 10

Characterizing Transactions
Fortunately, we really have to worry about only two primary operations to characterize transactions
Read - R(x) Write - W (x)

Sets of transaction data from our last example

Read Set (RS) = {PART.parts_sold, PART.total_parts} Write Set (WS) = {PART.parts_sold, ORDER.pno, ORDER.sno, ORDER.special} Base Set (BS) = RS WS = {PART.parts_sold, PART.total_parts, ORDER.pno, ORDER.sno, ORDER.special}

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

11

More Transaction Characterization

We are simplifying the transaction problem a little
Only characterizing RW operations Not Insert and Delete operations Thus, we are talking about static databases Dynamic databases worry about Insert and Delete operations
Deal with phantom records (to be covered soon) Very similar to RW issues

Say that Oij(x) is some operation Oj on x in transaction Ti

Oij { read, write } OSi is the set of operations in Ti (i.e., OSi = Oij ) Ni are the termination conditions for Ti where Ni { abort, commit }

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

12

Formal Transaction Definition

Define transaction Ti as the partial ordering of all its operations and terminations Partial order P = { , p } defines an ordering among the elements of the domain
p is not reflective, but it is transitive Ti is a partial order { i, p i } where
i = OSi Ni For any two operations Oij, Oik OSi : if Oij = (R(x) or W(x)) and Oik = W(x), then either Oij p i Oik or Oik p i Oij Oij OSi , Oij p i Ni

The specific operations and ordering are application dependent There must be ordering between conflicts
Read Write conflicts Write Write conflicts

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

13

Simple Example
Transaction 1. Read(x) 2. Read(y) 3. x <- x+y 4. Write(x) 5. Commit Directed Acyclic Graph (DAG) representation of the operations and partial ordering of the transaction:
R(x) W(x) R(y) C

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

14

Operation and Partial Ordering Notation

Operations and partial ordering
= { R(x), R(y), W(x), C } p = { (R(x), W(x)), (R(y), W(x)), (W(x), C), (R(x), C), (R(y), C) }

Since we understand the partial ordering rules, we can just use relative ordering notation:
T = {R(x), R(y), W(x), C} We understand from this this the partial ordering rules above

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

15

Operation and Partial Ordering Notation of the Parts Sold Example

Abort notation
= { R(parts_sold), R(total_parts), A } p = { (R(parts_sold), A), (R(total_parts), A) }

Commit notation
= { R(parts_sold), R(total_parts), W(parts_sold), W(pno), W(sno), W(special), C } p = { (R(parts_sold), W(parts_sold)), (R(total_parts), W(parts_sold)), (R(parts_sold), W(pno)), (R(parts_sold), W(sno)), (R(parts_sold), W(special)), (R(total_parts), W(pno)), (R(total_parts), W(sno)), (R(total_parts), W(special)), (R(parts_sold), C), (R(total_parts), C), (W(parts_sold), C), (W(sno), C), (W(special),C) }

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

16

Properties of Database Consistency

The common properties of database consistency have been labeled ACID properties
ACID properties define ideal consistency management for data Some properties are overlapping

ACID stands for

Atomicity Consistency Isolation Durability

Concurrency Control implements Consistency and Isolation Recovery Management implements Atomicity and Durability

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

17

Atomicity
Transaction is a unit of operation
All transactions either complete or not "All-or-nothing" property

If failure occurs, DBMS must either undo parts of transactions or complete them at a later time Two types of failures
Logic errors
Data errors Deadlocks Consistency -> Transaction aborts itself or DBMS aborts Media errors System crashes Network problems -> In these cases, we need crash recovery

System crashes

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

18

Consistency
Consistency = correctness A transaction maps one consistent database state to another Verifying transaction consistency is the job of the semantic data controller Ensuring transaction consistency is the job of the concurrency controller

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

19

Isolation
Each transaction must see a consistent database at all times The transaction effects cannot be seen by other transactions before the transaction is complete Concurrent transactions must be executed with the appearance that they were done in some linear order. Problems encountered
Dirty Read Non-Repeatable Read Phantom Read Overwriting Uncommitted Data
Distributed Database Systems Introduction to Transaction Mgmt. 20

D. Silberberg

Dirty Read (Lost Update) Problem

Reading uncommitted data Write-Read conflicts Example:

T1:

T1 transfers $100 from one account to another. T2 adds 6% to each account

read(x) x = x-100 write(x) T2:

read(x) x = 1.06* x write(x) read(y) y = 1.06* y write(y) commit read(y) x = x+100 write(y) commit

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

21

Dirty Reads - Continued

Suppose Account X had $200 and Account Y had $100 If T1 runs entirely before T2
Account X transfers $100 to Account Y X = $100 and Y = $200 Then T2 adds 6% -> X = $106 and Y = $212 X+Y = $318 T2 adds 6% -> X = $212 and Y = $106 Account X transfers $100 to Account Y X = $112 and Y = $206 X+Y = $318 After the first T1 operation, X = $100, Y = $100 T2 adds 6% -> X = $106, Y = $106 Then, T1 adds the $100 back into Y, X = $106, Y = $206 X+Y = $312

If T2 runs entirely before T1

In our scenario

Transaction 1 loses money!

Distributed Database Systems Introduction to Transaction Mgmt. 22

D. Silberberg

Non-repeatable (Fuzzy) Read Problem

Read-Write Conflicts T1: read(balance) ($100) balance=balance-100 ($0) read(balance) ($100) balance=balance-50 ($50) write(balance) ($50) if (balance <= 50) read(balance) ($50) write(balance) ($50) commit abort Transaction 1 loses money! T2:

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

23

Phantom Reads
Read-Write conflicts T2:

T1: read(deposit list) print(deposit list)

write(new deposit) commit read(deposit list) write(deposit list) Commit Transaction 1 does not have what is indicated on the deposit slip!
D. Silberberg Distributed Database Systems Introduction to Transaction Mgmt. 24

Overwriting Uncommitted Data

Employees x and y must maintain a consistent salary. T1 sets both salaries to $4000/month and T2 sets both salaries to $5000/month. Neither transaction reads their current salaries

T1: x = 4000 write(x)

T2:

y = 5000 write(y) y = 4000 write(y) commit x = 5000 write(x) commit

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

25

Durability
Once transaction commits, it is permanent Transaction will survive subsequent failures

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

26

Transaction Architecture for Distributed DBMS

Need to add a Transaction Manager (TM) and a Scheduler (SC)
TM coordinates transactions for all applications SC implements specific concurrency algorithm for synchronous access to databases Need local recovery managers to rollback transactions

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

27

Transaction Managers Implement 5 Commands

Begin set up new transaction. Keep information useful in case a rollback occurs Read if the value is local, read it from the local site. If not, select one site and read it from there Write write value to all sites that store the value Commit coordinates all sites to inform them that the write from a transaction is permanent Abort coordinates all sites to inform them that all writes of a transaction must not be permanently recorded
begin, write, etc. Distributed Execution Monitor results

TM

other SCs

other TMs

SC

data processors

D. Silberberg

Distributed Database Systems Introduction to Transaction Mgmt.

28