© Michael Lang, National University of Ireland, Galway 1 Transaction Management

© Michael Lang, National University of Ireland, Galway 2 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

© Michael Lang, National University of Ireland, Galway 3 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

© Michael Lang, National University of Ireland, Galway 4 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.

© Michael Lang, National University of Ireland, Galway 5 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

© Michael Lang, National University of Ireland, Galway 6 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

© Michael Lang, National University of Ireland, Galway 7 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

© Michael Lang, National University of Ireland, Galway 8 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.

© Michael Lang, National University of Ireland, Galway 9 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.

© Michael Lang, National University of Ireland, Galway 10 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

© Michael Lang, National University of Ireland, Galway 11 COMMIT and ROLLBACK { TRANSACTION

© Michael Lang, National University of Ireland, Galway 12 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

© Michael Lang, National University of Ireland, Galway 13 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

© Michael Lang, National University of Ireland, Galway 14 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...

© Michael Lang, National University of Ireland, Galway 15 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

© Michael Lang, National University of Ireland, Galway 16 Problem: “The Lost Update” A/C NO BALANCE : : ,750 : : 13:30:06 Deposit 750 COMMIT A/C NO BALANCE : : ,700 : : 13:30:08 Withdraw 300 COMMIT Partner A 13:30:03 Balance 5,000 A/C NO BALANCE : : ,000 : : Partner B 13:30:04 Balance 5,000

© Michael Lang, National University of Ireland, Galway 17 Problem: “The Lost Update” 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 !!!

© Michael Lang, National University of Ireland, Galway 18 (Transaction T1) PROD_QOH = PROD_QOH (Transaction T2) PROD_QOH = PROD_QOH - 30 Problem: “The Lost Update”

© Michael Lang, National University of Ireland, Galway 19 Problem: “Dirty Data” Partner B 13:03:30 Request to withdraw 500 Balance -1,000 Withdrawal Refused Partner A 13:03:25 Balance 3,000 A/C NO BALANCE : : ,000 : : A/C NO BALANCE : : ,000 : : 13:03:28 Withdraw 4,000 A/C NO BALANCE : : ,000 : : 13:03:31 ROLLBACK

© Michael Lang, National University of Ireland, Galway 20 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 !!!

© Michael Lang, National University of Ireland, Galway 21 (Transaction T1) PROD_QOH = PROD_QOH (ROLLBACK) (Transaction T2) PROD_QOH = PROD_QOH - 30 Problem: “Dirty Data”

© Michael Lang, National University of Ireland, Galway 22 Problem: “Phantom Data” Partner B 13:03:28 Balance Query 5,000 Partner A 13:03:25 Balance 5,000 A/C NO BALANCE : : ,000 : : 13:03:31 Balance Query 3,000 ??? A/C NO BALANCE : : ,000 : : 13:03:29 Withdraw 2,000 COMMIT

© Michael Lang, National University of Ireland, Galway 23 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

© Michael Lang, National University of Ireland, Galway 24 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

© Michael Lang, National University of Ireland, Galway 25 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)

© Michael Lang, National University of Ireland, Galway 26 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 1 1 Record 1 Update transaction (User B) Lock record 2 Record 2 2 Attempt to lock Record Attempt to lock Record 2

© Michael Lang, National University of Ireland, Galway 27 Deadlock Prevention Give each transaction a timestamp. “Older” transactions have higher priority Assume T p requests a lock, but T q holds a conflicting lock. We can follow either of two strategies:  “Wait-Die”: if T p has higher priority, it waits; else T p aborts  “Wound-Wait”: if T p has higher priority, abort T q ; else T p 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

© Michael Lang, National University of Ireland, Galway 28 Deadlock Detection Lock Manager maintains a “Waits-for” graph:  Node for each transaction  Arc from T i to T j if T j holds a lock and T i 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

© Michael Lang, National University of Ireland, Galway 29 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

© Michael Lang, National University of Ireland, Galway 30 Further Reading See recommended course textbooks:  Welling & Thomson (2004) MySQL Tutorial, Chapter 10  Rob & Coronel (2007) Database Systems, Chapter 10