© michael lang, national university of ireland, galway 1 transaction management
Post on 21-Dec-2015
217 views
TRANSCRIPT
© Michael Lang, National University of Ireland, Galway1
Transaction Manageme
nt
© Michael Lang, National University of Ireland, Galway2
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, Galway3
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, Galway4
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, Galway5
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, Galway6
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, Galway7
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, Galway8
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, Galway9
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, Galway10
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, Galway11
COMMIT and ROLLBACK
DATABASEBEFORE
INSERT
UPDATE
INSERT
DELETE
DATABASEAFTER
DATABASEBEFORE
INSERT
UPDATE
INSERT
ERROR !
DATABASEBEFORE
INSERT
UPDATE
HARDWAREFAILURE{
TRANSACTION
© Michael Lang, National University of Ireland, Galway12
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, Galway13
• 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, Galway14
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, Galway15
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, Galway16
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
© Michael Lang, National University of Ireland, Galway17
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, Galway18
(Transaction T1) PROD_QOH = PROD_QOH + 100
(Transaction T2) PROD_QOH = PROD_QOH - 30
Problem: “The Lost Update”
© Michael Lang, National University of Ireland, Galway19
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
© Michael Lang, National University of Ireland, Galway20
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, Galway21
(Transaction T1) PROD_QOH = PROD_QOH + 100 (ROLLBACK)
(Transaction T2) PROD_QOH = PROD_QOH - 30
Problem: “Dirty Data”
© Michael Lang, National University of Ireland, Galway22
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
© Michael Lang, National University of Ireland, Galway23
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, Galway24
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, Galway25
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, Galway26
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
© Michael Lang, National University of Ireland, Galway27
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
© Michael Lang, National University of Ireland, Galway28
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
© Michael Lang, National University of Ireland, Galway29
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, Galway30
Further Reading
• See recommended course textbooks:
Welling & Thomson (2004) MySQL Tutorial, Chapter 10
Rob & Coronel (2007) Database Systems, Chapter 10