Information Management Ecosystem Partnerships IBM Canada Lab Summer/Fall 2010

Data Concurrency

Information Management

2010 IBM Corporation

Information Management

Agenda

Database Transactions Concurrency Concurrency Issues Concurrency Control Isolation Levels Locking Specifying Isolation Levels

2010 IBM Corporation

Information Management

Database Transactions

Transaction sequence of one or more SQL operations, grouped together as a single unit that occurs in one atomic action also known as a unit of work After a transaction to the database is made it can be made permanent (committed) or backed out (rolled back) manual-commit: use COMMIT or ROLLBACK statements auto-commit: database manager performs a commit operation after every SQL statement Initiation and termination of a transaction defines the point of data consistency of data with the database committed data versus uncommitted data
2010 IBM Corporation

Information Management

Database Transactions

Committed Data data consistent with the database changes can always become committed data manually using a COMMIT statement committed data can only be reversed/removed with new SQL statements (within a new transaction) accessible to all users and applications Uncommitted Data data inconsistent with the database changes that occur during the transaction before a COMMIT statement is executed changes can be reversed with ROLLBACK inaccessible to other users and applications unless Uncommitted Read is used
2010 IBM Corporation

Information Management

Database Transactions

Connection to a database defines first initiation

empID
100 200

CONNECT TO DB employees INSERT INTO employee VALUES (100, 'JOHN') INSERT INTO employee VALUES (200, 'MANDY') COMMIT

name
JOHN MANDY

DELETE FROM employee WHERE name='MANDY' UPDATE employee SET empID=101 where name='JOHN' ROLLBACK No changes applied due to ROLLBACK

empID
100 200

name
JOHN MANDY

empID

name
JACK MANDY
2010 IBM Corporation

UPDATE employee SET name='JACK' where empID=100 COMMIT ROLLBACK

5

100 200

Information Management

Concurrency

Concurrency Sharing of resources by multiple interactive users or application programs at the same time Having multiple interactive users can lead to: Lost Update Uncommitted Read Non-repeatable Read Phantom Read Need to be able to control the degree of concurrency: With proper amount of data stability Without loss of performance

2010 IBM Corporation

Information Management

Concurrency Issues

Lost Update Occurs when two transactions read and then attempt to update the same data, the second update will overwrite the first update before it is committed 1) Two applications, A and B, both read the same row and calculate new values for one of the columns based on the data that these applications read 2) A updates the row 3) Then B also updates the row 4) A's update lost

2010 IBM Corporation

Information Management

Concurrency Issues

Uncommitted Read Occurs when uncommitted data is read during a transaction Also known as a Dirty Read

1) Application A updates a value 2) Application B reads that value before it is committed 3) A backs out of that update 4) Calculations performed by B are based on the uncommitted data

2010 IBM Corporation

Information Management

Concurrency Issues

Non-repeatable Read Occurs when a transaction reads the same row of data twice and returns different data values with each read

1) Application A reads a row before processing other requests 2) Application B modifies or deletes the row and commits the change 3) A attempts to read the original row again 4) A sees the modified row or discovers that the original row has been deleted

2010 IBM Corporation

Information Management

Concurrency Issues

Phantom Read Occurs when a search based on some criterion returns additional rows after consecutive searches during a transaction 1) Application A executes a query that reads a set of rows based on some search criterion 2) Application B inserts new data that would satisfy application A's query 3) Application A executes its query again, within the same unit of work, and some additional phantom values are returned

10

2010 IBM Corporation

Information Management

Concurrency Control

Isolation Levels determine how data is locked or isolated from other concurrently executing processes while the data is being accessed are in effect while the transaction is in progress There are four levels of isolation in DB2: Repeatable read Read stability Cursor stability
Currently Committed

Uncommitted read

11

2010 IBM Corporation

Information Management

Locking

Isolation levels are enforced by locks locks limit or prevent data access by concurrent users or application processes Locking Attributes resource being locked is called object objects which can be explicitly locked are databases, tables and table spaces objects which can be implicitly locked are rows, index keys, and tables implicit locks are acquired by DB2 according to isolation level and processing situations object being locked represents granularity of lock length of time a lock is held is called duration and is affected by isolation level

12

2010 IBM Corporation

Information Management

Types of Locks

Share (S) concurrent transactions are limited to read-only operations Update (U) concurrent transactions are limited to read-only operations if the transactions have not declared that they might update a row, the database manager assumes that transaction currently looking at a row might update it Exclusive (X) concurrent transactions are prevented from accessing the data in any way does not apply to transactions with an isolation level of UR Database manager places exclusive locks on every row that is inserted, updated, or deleted

13

2010 IBM Corporation

Information Management

Deadlock

Deadlock Occurs when 2 (or more) competing operations are waiting for each other to free some resource, but neither does, thus the operations will never finish. Eg:

App1 modifies row 1 on Table A it holds an X lock on it App2 modifies row 5 on Table B It holds an X lock on it App2 tries to modify row 1 on Table A but it can't since App1 has the lock. It goes into WAIT App1 tries to modify row 5 on Table B but it can't since App2 has the lock. It goes into WAIT DEADLOCK as both operations can not complete

Deadlock Detector discovers deadlock cycles

randomly selects one of the transactions involved to roll back and terminate transaction chosen is then sent an SQL error code, and every lock it had acquired is released

14

2010 IBM Corporation

Information Management

Repeatable Read

Highest level of isolation No dirty reads, non-repeatable reads or phantom reads Locks the entire table or view being scanned for a query Provides minimum concurrency When to use Repeatable Read: Changes to the result set are unacceptable Data stability is more important than performance

15

2010 IBM Corporation

Information Management

Read Stability

Similar to Repeatable Read but not as strict No dirty reads or non-repeatable reads Phantom reads can occur Locks only the retrieved or modified rows in a table or view When to use Read Stability: Application needs to operate in a concurrent environment Qualifying rows must remain stable for the duration of the unit of work Only issue unique queries during a unit of work
If the same query is issued more than once during a unit of work, the same result set should not be required

16

2010 IBM Corporation

Information Management

Cursor Stability

Default isolation level No dirty reads Non-repeatable reads and phantom reads can occur Locks only the row currently referenced by the cursor When to use Cursor Stability: Want maximum concurrency while seeing only committed data

17

2010 IBM Corporation

Information Management

Currently Committed

Currently Committed is a variation on Cursor Stability Avoids timeouts and deadlocks Log based:
No management overhead

Cursor Stability
Situation Reader blocks Reader Reader blocks Writer Writer blocks Reader Writer blocks Writer Result No Maybe Yes Yes

Currently Committed
Situation Reader blocks Reader Reader blocks Writer Writer blocks Reader Writer blocks Writer Result No No No Yes

18

2010 IBM Corporation

Information Management

Currently Committed

Up to DB2 9.5 Cursor Stability is the default isolation level Now in DB2 9.7 Currently Committed is the default for NEW databases Currently Committed is disabled for upgraded databases, i.e., Cursor Stability semantics are used Applications that depend on the old behavior (writers blocking readers) will need to update their logic or disable the Currently Committed semantics

19

2010 IBM Corporation

Information Management

Example Cursor Stability Semantics

Transaction A
update T1 set col1 = ? where col2 = 2 update T2 set col1 = ? where col2 = ? select * from T2 where col2 >= ? select * from T1 where col5 = ? and col2 =?

Transaction B

Waiting because is reading uncommitted data

Waiting because is reading uncommitted data

DEADLOCK!!
20 2010 IBM Corporation

Information Management

Example Currently Committed Semantics

Transaction A
update T1 set col1 = ? where col2 = 2 update T2 set col1 = ? where col2 = ? select * from T2 where col2 >= ? select * from T1 where col5 = ? and col2 =? commit commit No locking Reads last committed version of the data No locking Reads last committed version of the data

Transaction B

No deadlocks, no timeouts in this scenario!

21 2010 IBM Corporation

Information Management

Currently Committed How to use it?

cur_commit DB config parameter ON: default for new DBs created in DB2 9.7 CC semantics in place DISABLED: default value for existing DBs old CS semantics in place PRECOMPILE/BIND CONCURRENTACCESSRESOLUTION: Specifies the concurrent access resolution to use for statements in the package.
USE CURRENTLY COMMITTED WAIT FOR OUTCOME

22

2010 IBM Corporation

Information Management

Uncommitted Read

Lowest level of isolation Dirty reads, non-repeatable reads and phantom reads can occur Locks only rows being modified in a transaction involving DROP or ALTER TABLE Provides maximum concurrency When to use Uncommitted Read: Querying read-only tables Using only SELECT statements Retrieving uncommitted data is acceptable Uncommitted Read with Read-Write tables UR behaves like CS with updateable cursors

23

2010 IBM Corporation

Information Management

Isolation Levels

Summary
Dirty Read Possible Non-repeatable Read Possible Possible Phantom Read Possible Possible Possible

Isolation Level Repeatable Read (RR) Read Stability (RS) Cursor Stability (CS) Uncommitted read (UR) Application Type

DEFAULT

High data stability required High data stability not required Read Stability (RS) Repeatable Read (RR) or Read Stability (RS) Cursor Stability (CS) Uncommited Read (UR)

Read-write transactions Read-only transactions

24

2010 IBM Corporation

Information Management

Specifying Isolation Levels

Precompile / Bind ISOLATION option of PREP or BIND command Can determine isolation level of a package by executing the following query

SELECT ISOLATION FROM syscat.packages WHERE pkgname = 'pkgname' AND pkgschema = 'pkgschema'

Statement Level Use the WITH {RR, RS, CS, UR} clause The WITH UR option applies only to read-only operations ensure that a result table is read-only by specifying FOR READ ONLY in the SQL statement Overrides the isolation level specified for the package

SELECT * FROM tb1 WITH RR

25 2010 IBM Corporation

Information Management

Specifying Isolation Levels

Dynamic SQL within the current session SET CURRENT ISOLATION For all subsequent dynamic SQL statements within the same session JDBC or SQLJ at run time SQLJ profile customizer (db2sqljcustomize command) CLI or ODBC at run time CHANGE ISOLATION LEVEL command specified during the program preparation process

CHANGE ISOLATION LEVEL TO RR

26

2010 IBM Corporation

Information Management Ecosystem Partnerships IBM Canada Lab

Questions? E-mail: [email protected] Subject: DB2 Academic Workshop

Summer/Fall 2010

Information Management

2010 IBM Corporation