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

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

DELETE FROM employee WHERE name='MANDY'

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

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

COMMIT
ROLLBACK
5

empID

name

100

JOHN

200

MANDY

empID

name

100

JOHN

200

MANDY

empID

name

100

JACK

200

MANDY
2010 IBM Corporation

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

12

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

2010 IBM Corporation

Information Management

Types of Locks

13

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

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

14

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

2010 IBM Corporation

Information Management

Repeatable Read

15

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

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

17

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

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

18

Currently Committed

Situation

Result

Situation

Result

Reader blocks Reader

No

Reader blocks Reader

No

Reader blocks Writer

Maybe

Reader blocks Writer

No

Writer blocks Reader

Yes

Writer blocks Reader

No

Writer blocks Writer

Yes

Writer blocks Writer

Yes

2010 IBM Corporation

Information Management

Currently Committed

19

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

2010 IBM Corporation

Information Management

Example Cursor Stability Semantics

Transaction A

Transaction B

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 = ?

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

Transaction B

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

No
Nodeadlocks,
deadlocks,no
notimeouts
timeoutsin
inthis
thisscenario!
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

23

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

2010 IBM Corporation

Information Management

Isolation Levels

24

Summary

Isolation Level

Dirty Read

Non-repeatable
Read

Phantom
Read

Repeatable Read (RR)

Read Stability (RS)

Possible

Cursor Stability (CS)

Possible

Possible

Uncommitted read (UR)

Possible

Possible

Possible

DEFAULT

Application Type

High data stability

required

High data stability not

required

Read-write transactions

Read Stability (RS)

Cursor Stability (CS)

Read-only transactions

Repeatable Read (RR) or

Read Stability (RS)

Uncommited Read (UR)

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?

Summer/Fall 2010

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

Information Management

2010 IBM Corporation