© michael lang, national university of ireland, galway 1 transaction management

© Michael Lang, National University of Ireland, Galway1

Transaction Manageme

nt


Transaction Management

• Updates to data typically occur in response to business events. For example, if a customer were to place an order this may require the following operations to be performed:

Update BALANCE in CUST_ACCOUNT table

Insert order details into the SALES_INVOICE table

Insert order details into the SALES_INV_LINE table

Update QTY_ON_HAND for each related item in the STOCK table

This may in turn trigger a purchase order


What is a Transaction ?“ A transaction is a sequence of one or more

SQL statements that together form a logical piece of work ” - Groff & Weinberg

• All statements within the transaction must be executed. Otherwise, data may be inconsistent and integrity is compromised.

• A transaction is an atomic unit:

it is an “all-or-nothing” proposition whereby ALL statements are successfully processed, or NONE are processed

“partial” transactions should never be permitted


What is a Transaction?

• A consistent database state is one in which all data integrity constraints are satisfied.

• Example: during transaction, no other transaction must access X.


The ACID Properties• Atomicity: All actions in the transaction happen, or

none happen

• Consistency: If each transaction is consistent, and the database starts consistent, it ends up consistent

• Isolation: Execution of one transaction is isolated from that of other transaction

• Durability: If a transaction commits, its effects persist


ANSI / ISO Transaction Model

• Most commercial SQL products adhere to the ANSI / ISO Transaction Model, which defines the roles of COMMIT and ROLLBACK

• A transaction is initiated by the first SQL statement to be executed

• A COMMIT statement successfully terminates the transaction, and the next SQL statement is understood to be part of a new transaction

• A ROLLBACK statement aborts the transaction, and the next SQL statement is understood to be part of a new transaction


ANSI / ISO Transaction Model

• With programmatic SQL the ANSI / ISO Transaction Model specifies that:

Successful termination of the program signals the end of a transaction and updates to data are committed

Abnormal termination of the program aborts transaction, and any updates that have been performed are undone


Transaction Management in MySQL

• With transaction-safe table types (InnoDB or BDB) …

BEGIN, BEGIN WORK, or START TRANSACTION is used to initiate a transaction.

COMMIT successfully terminates the current transaction, but does not automatically initiate a new one.

SAVEPOINT identifier may be used “mid-stream” to allocate a save point. The data is not yet committed however.

ROLLBACK backs out as far as the beginning of the transaction.

ROLLBACK TO SAVEPOINT identifier backs out as far as a specified savepoint.

RELEASE SAVEPOINT removes the named savepoint from the set of savepoints of the current transaction. No commit or rollback occurs.


Transaction Management in MySQL

• You may need to specify the InnoDB table type in your CREATE TABLE statement:

CREATE TABLE tablename ( …) TYPE = InnoDB;

• By default, autocommit behaviour is set to ON (1). You can change this by typing

SET AUTOCOMMIT = 0;

• See the sample SQL script on the course Web page with examples of COMMIT, ROLLBACK, etc.


COMMIT and ROLLBACK

• COMMIT Statement:

Occurs at the end of a successful complete transaction

Data inserted and updated are committed to the database and the transaction cannot be reversed except by executing the opposite set of statements in reverse

• ROLLBACK Statement:

This is similar to the notion of an “undo” facility whereby the effect of the previously executed SQL statement(s) is to be reversed

It “backs out” and restores the database to its state immediately after the most recent COMMIT statement


COMMIT and ROLLBACK

DATABASEBEFORE

INSERT

UPDATE

INSERT

DELETE

DATABASEAFTER

DATABASEBEFORE

INSERT

UPDATE

INSERT

ERROR !

DATABASEBEFORE

INSERT

UPDATE

HARDWAREFAILURE{

TRANSACTION


Transaction Logs• How does a DBMS back out of a transaction ? Most

systems do so by maintaining Transaction Logs, which records all operations as well as COMMIT statements

• When a ROLLBACK command is issued, the log is examined and the operations are undone in reverse chronological order back as far as the most recent COMMIT

• If the transaction is incomplete because of software / hardware failure, the DBMS typically invokes some form of recovery utility to restore the log and then rollback all uncommitted operations

• Logging is taxing on system resources, but is vital in multi-user environments

• Typically, the log is maintained in a separate area from the database so as to avoid access contention


• TRL_ID: transaction log record ID

• TRX_NUM: transaction number

• PREV_PTR: pointer to previous transaction record

• NEXT_PTR: pointer to next transaction record

Transaction Logs


Concurrent Data Access

• It is common for multiple users to have concurrent access to a database. Some of the reasons are: better transaction throughput and response time

better utilisation of resources - while one process is doing a disk read, another can be using the CPU or reading another disk

DANGER DANGER ! Concurrency can lead to incorrectness ...


Problems• If many users can potentially access the same data

concurrently, known problems can arise ...

• Lost Update Problem: The first update is lost and the database is in an inconsistent state

as Transaction B was allowed to access same data as Transaction A before it was completed

• Uncommitted “Dirty” Data Problem: Transaction B is fed data uncommitted by Transaction A which can

result in a false decision being made

• Inconsistent “Phantom” Data Problem: Transaction B performs the same query twice but returns different

results. It reflects the real state of the database, but is confusing to Transaction B


Problem: “The Lost Update”

A/C NO BALANCE

: :89743589 5,750 : :

13:30:06Deposit 750

COMMIT

A/C NO BALANCE

: :89743589 4,700 : :

13:30:08Withdraw 300

COMMIT

Partner A

13:30:03Balance 5,000

A/C NO BALANCE : :89743589 5,000 : :

Partner B

13:30:04Balance 5,000



• Another example (airline reservations): Customer 1 finds a seat empty

Customer 2 finds the same seat empty, before Customer 1 has finalised his reservation

Customer 1 reserves the seat for himself

Customer 2 reserves the seat for herself

Customer 1 will not be happy !!!


(Transaction T1) PROD_QOH = PROD_QOH + 100

(Transaction T2) PROD_QOH = PROD_QOH - 30



Problem: “Dirty Data”

Partner B

13:03:30Request to withdraw

500

Balance -1,000Withdrawal Refused

Partner A

13:03:25Balance 3,000

A/C NO BALANCE : :89743589 3,000 : :

A/C NO BALANCE

: :89743589 -1,000 : :

13:03:28Withdraw 4,000

A/C NO BALANCE : :89743589 3,000 : :

13:03:31ROLLBACK


Problem: “Dirty Data”• Another example (airline reservations):

Customer 1 finds a seat empty, and places a hold

Customer 2 finds no seat, and next flight is tomorrow

Customer 1 decides the fare is too high, and cancels

Customer 2 is not advised that seat is now available

Customer 2 will not be happy !!!


(Transaction T1) PROD_QOH = PROD_QOH + 100 (ROLLBACK)

(Transaction T2) PROD_QOH = PROD_QOH - 30

Problem: “Dirty Data”


Problem: “Phantom Data”

Partner B

13:03:28Balance Query

5,000

Partner A

13:03:25Balance 5,000

A/C NO BALANCE : :89743589 5,000 : :

13:03:31Balance Query

3,000 ???

A/C NO BALANCE

: :89743589 3,000 : :

13:03:29Withdraw 2,000

COMMIT


Problem Prevention• The DBMS must ensure that a user will see an

entirely consistent view of the database at all times:

the uncommitted changes of other users are invisible

even committed changes do not affect data seen by user in mid-transaction.

• Therefore, if Transaction A and Transaction B are being concurrently executed, the results will be the same regardless of whether Transaction A is completed and then followed by B, or Transaction B is completed and then followed by A

this is the principle of serialisation


Locking• Concurrency management is normally controlled by

locking mechanisms

• Locks temporarily give a user exclusive write access to data

• There are levels of locking: table, page, record, etc.

• Locks may be shared, or exclusive

• The lock manager maintains a list of entries: object identifier (page, record, etc.)

number of transactions holding lock on the object

nature of the lock (shared or exclusive)

list of lock requests


Lock Management• When a lock is released ...

Update list of transactions holding lock

Examine head of wait queue

If transaction at head of queue can run, add it to list of transactions holding lock (change mode as needed)

Repeat until head of wait queue cannot be run (deadlock)


Problem: “The Deadly Embrace”

• A transaction deadlock (stalemate) can arise as follows:

User A’s update transaction locks record 1

User B’s update transaction locks record 2

User A attempts to read record 2 for update

User B attempts to read record 1 for update

Update transaction(User A)

Lock record 11

Record 1

Update transaction(User B) Lock record 2 Record 2

2

Attempt to lock Record 13

4 Attempt to lock Record 2


Deadlock Prevention• Give each transaction a timestamp. “Older”

transactions have higher priority

• Assume Tp requests a lock, but Tq holds a conflicting lock. We can follow either of two strategies:

“Wait-Die”: if Tp has higher priority, it waits; else Tp aborts

“Wound-Wait”: if Tp has higher priority, abort Tq; else Tp waits.

• After aborting, restart with original timestamp• In theory, deadlock can involve many transactions:

T1 waits-for T2 waits-for T3 … waits-for T1• In practice, most “deadlock cycles” involve only two

transactions


Deadlock Detection

• Lock Manager maintains a “Waits-for” graph: Node for each transaction

Arc from Ti to Tj if Tj holds a lock and Ti is waiting for it

• Periodically, check graph for cycles - if a cycle is found, abort some transaction to break it

• A simpler approach is to specify time-out periods - if a transaction has made no progress for a while, abort it


Detection -v- Prevention

• Prevention might abort too many transactions

• Detection might allow deadlocks to tie up resources for a while. We could detect more frequently, but it’s time-consuming

• The usual workaround: Detection is the winner

Deadlocks are pretty rare

If you get a lot of deadlocks, reconsider your schema / workload


Further Reading

• See recommended course textbooks:

Welling & Thomson (2004) MySQL Tutorial, Chapter 10

Rob & Coronel (2007) Database Systems, Chapter 10

© michael lang, national university of ireland, galway 1 transaction management

Documents

transaction commits

transaction durability

current transaction

transaction management

new transaction slide

transaction management

program aborts transaction

ansi iso transaction