17 Introduction to Transaction Management

8/13/2019 17 Introduction to Transaction Management

1/28

Distributed Database SystemsIntroduction to Transaction Management

(Ozsu Chap. 10.1, 10.2 & 10.4)

605.741

David Silberberg


2/28

D. Silberberg Distributed Database Systems

Introduction to Transaction Mgmt.

2

Introduction

Up until now, we have concentrated on querymanagement Planning

Optimization

Execution

However, we need to make the distributed databasesystem more robust Failures (e.g., site crashes)

Conflicts (e.g., two queries simultaneously updating thedatabase)

We want consistent execution and reliable computation

Transactions provides both consistency and reliability


3/28



3

Transaction Management Definitions

Database consistency Obeys integrity checks

Foreign keys Cascading deletes, if specified

Database is usually inconsistent during an operation, butconsistent 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


4/28


5/28


6/28


7/28


8/28



8

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");


9/28



9

Realistic Example ABORT Condition

if (rs.next()) // ifused 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}


10/28



10

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(); // COMMITSystem.out.println("Order processed!") // after COMMIT

}

}


11/28


12/28



12

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 }


13/28



13

Formal Transaction Definition

Define transaction Ti as the partial ordering of all its operationsand terminations

Partial order P = { , p } defines an ordering among theelements 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


14/28



14

Simple Example

Transaction

1. Read(x)

2. Read(y)

3. x


15/28



15

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, wecan just use relative ordering notation: T = {R(x), R(y), W(x), C}

We understand from this this the partial ordering rules above


16/28



16

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) }


17/28



17

Properties of Database Consistency

The common properties of database consistency have beenlabeled 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


18/28



18

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 transactionsor complete them at a later time

Two types of failures Logic errors

Data errors Deadlocks Consistency -> Transaction aborts itself or DBMS aborts

System crashes Media errors System crashes Network problems -> In these cases, we need crash recovery


19/28



19

Consistency

Consistency = correctness

A transaction maps one consistent database state toanother

Verifying transaction consistency is the job of thesemantic data controller

Ensuring transaction consistency is the job of theconcurrency controller


20/28



20

Isolation

Each transaction must see a consistent database atall times

The transaction effects cannot be seen by othertransactions before the transaction is complete

Concurrent transactions must be executed with the

appearance that they were done in some linearorder.

Problems encountered Dirty Read

Non-Repeatable Read

Phantom Read

Overwriting Uncommitted Data


21/28



21

Dirty Read (Lost Update) Problem

Reading uncommitted data Write-Read conflicts Example:

T1 transfers $100 from one account to another.

T2 adds 6% to each account

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

read(x)x = 1.06* xwrite(x)read(y)y = 1.06* ywrite(y)

commitread(y)x = x+100write(y)commit


22/28



22

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

If T2 runs entirely before T1 T2 adds 6% -> X = $212 and Y = $106 Account X transfers $100 to Account Y X = $112 and Y = $206 X+Y = $318

In our scenario

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

Transaction 1 loses money!


23/28



23

Non-repeatable (Fuzzy) Read Problem

Read-Write Conflicts

T1: T2:read(balance) ($100)balance=balance-100 ($0)

read(balance) ($100)balance=balance-50 ($50)

write(balance) ($50)if (balance


24/28



24

Phantom Reads

Read-Write conflicts

T1: T2: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!


25/28



25

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: T2:x = 4000write(x)

y = 5000write(y)

y = 4000write(y)commit

x = 5000write(x)commit


26/28



26

Durability

Once transaction commits, it is permanent

Transaction will survive subsequent failures


27/28



27

Transaction Architecture for Distributed DBMS

Need to add a Transaction Manager (TM) and aScheduler (SC) TM coordinates transactions for all applications

SC implements specific concurrency algorithm forsynchronous access to databases

Need local recovery managers to rollback transactions


28/28



28

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 fromthere

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 bepermanently recorded

DistributedExecutionMonitor TM

SC

other SCs

other TMs

data processors

resultsbegin, write, etc.

17 Introduction to Transaction Management

Documents