1.5 - Data Concurrency and Locking

Data concurrency and locking
IBM Information Management Cloud Computing Center of Competence

IBM Canada Labs
1 © 2011 IBM Corporation
Agenda
• Transactions
• Concurrency & Locking
• Lock Wait
• Deadlocks

Supporting reading material & videos
• Reading materials
• Getting started with DB2 Express-C eBook
• Chapter 13: Concurrency and locking
• Videos
• db2university.com course AA001EN
• Lesson 8: Data concurrency and locking

Agenda
• Transactions
• Lock Wait
• Deadlocks

What is a transaction?
Your bank account Your Mom’s bank account
Balance = $1000 Balance = $200
Transfer $100 from your account to your Mom’s account:

- Debit $100 from your bank account (Subtract $100)
- Credit $100 to your mom's bank account (Add $100)

What is a transaction? (cont'd)
• One or more SQL statements altogether treated as one

single unit
• Also known as a Unit of Work (UOW)
• A transaction starts with any SQL statement and ends with
a COMMIT or ROLLBACK
• COMMIT statement makes changes permanent to the
database
• ROLLBACK statement reverses changes
• COMMIT and ROLLBACK statements release all
locks

Example of transactions
First SQL st atemen
starts trans t
action
INSERT INTO employee VALUES (100, 'JOHN' )
INSERT INTO employee VALUES (200, 'MANDY')
COMMIT
No changes
applied due to
ROLLBA K
C
DELETE FROM employee WHERE name='MAND Y'
UPDATE employee SET empID=101 where name='JOHN'
ROLLBACK
UPDATE employee SET name='JACK' where empID=100

COMMIT There is not hing to
rollback
ROLLBACK
Transactions – ACID rules
• Atomicity
• All statements in the transaction are treated as a unit.
• If the transaction completes successfully, everything is committed
• If the transaction fails, everything done up to the point of failure is rolled back.
• Consistency
• Any transaction will take the data from one consistent state to another, so only
valid consistent data is stored in the database
• Isolation
• Concurrent transactions cannot interfere with each other
• Durability
• Committed transactions have their changes persisted in the database
Agenda
• Transactions
• Lock Wait
• Deadlocks

Concurrency and Locking
App A
ID Name Age
App B 3 Peter 33
5 John 23
App C 22 Mary 22
35 Ann 55
App
• Concurr
ency:
• Multiple users accessing the same resources at the
same time
10
• Locking: © 2011 IBM Corporation
Locking
• Locks are acquired automatically as needed to support a

transaction based on “isolation levels”
• COMMIT and ROLLBACK statements release all locks
• Two basic types of locks:

• Share locks (S locks) – acquired when an application wants to
read and prevent others from updating the same row
• Exclusive locks (X locks) – acquired when an application
updates, inserts, or deletes a row

Problems if there is no concurrency control
• Lost update
• Uncommitted read
• Non-repeatable read
• Phantom read

Lost update
reservations
seat name ...
7C
7B
...
App A App B

Lost update
reservations
seat name ...
7C
7B
...
App A App B
update reservations
set name =
'John' where
seat = '7C'

Lost update
reservations
seat name ...
7C _____
John
7B
...
App A App B
update reservations
set name =
'John' where
seat = '7C'

Lost update
reservations
seat name ...
7C _____
John
7B
...
App A App B
update reservations update reservations

set name = set name =
'John' where 'Mary' where
seat = '7C' seat = '7C'

Lost update
reservations
seat name ...
7C _____
Mary
Joh
7B n
...
App A App B


Lost update
reservations
seat name ...
7C M? ary
_____
Joh
7B n
...
App A App B


Uncommitted read (also known as “dirty read”)
reservations
seat name ...
7C
7B
...
App A App B

reservations
seat name ...
7C
7B
...
App A App B
update reservations
set name =
'John' where
seat = '7C'

reservations
seat name ...
7C _____
John
7B
...
App A App B
update reservations
set name =
'John' where
seat = '7C'

reservations
seat name ...
7C _____
John
7B
...
App A App B
update reservations Select name
set name = from reservations
'John' where where seat is
seat = '7C' '7C'

reservations
seat name ...
7C _____
John
7B
...
App A App B
set name = from reservations John
seat = '7C' '7C'

reservations
seat name ...
7C _____
John
7B
...
App A App B
seat = '7C' '7C'
Roll back

reservations
seat name ...
7C
7B
...
App A App B
seat = '7C' '7C'
Roll back

reservations
seat name ...
7C
7B
...
App A App B
seat = '7C' '7C' processing in Ap p
Further
B uses incorrect /
uncommitted value of
Roll back “John”

Non-repeatable read
reservations
seat name ...
7C
7B
...
App A App B

Non-repeatable read
reservations
seat name ...
7C
7B
...
App A App B
select seat
from reservations
where name is NULL

Non-repeatable read
reservations
seat name ...
7C
7B
...
App A App B
7C select seat
from reservations
7B
where name is NULL

Non-repeatable read
reservations
seat name ...
7C
7B
...
App A App B
7C select seat update reservations

from reservations set name =
7B 'John' where
where name is NULL
seat = '7C'

Non-repeatable read
reservations
seat name ...
7C _____
John
7B
...
App A App B

7B 'John' where
where name is NULL
seat = '7C'

Non-repeatable read
reservations
seat name ...
7C _____
John
7B
...
App A App B

7B 'John' where
where name is NULL
seat = '7C'
...
select seat
from reservations
where name is NULL

Non-repeatable read
reservations
seat name ...
7C _____
John
7B
...
App A App B

7B 'John' where
where name is NULL
seat = '7C'
...
select seat
7B from reservations
where name is NULL

Non-repeatable read
reservations
seat name ...
7C _____
John
7B
...
App A App B

7B 'John' where
where name is NULL
seat = '7C'
... The same SELECT (read) returns a
select seat different result: Less rows (in this
7B from reservations case '7C' doesn't show anymore).
where name is NULL This is a non-repeatable read

Phantom read
reservations
seat name ...
7C _____
Susan
7B
...
App A App B

Phantom read
reservations
seat name ...
7C _____
Susan
7B
...
App A App B
select seat
from reservations
where name is NULL

Phantom read
reservations
seat name ...
7C _____
Susan
7B
...
App A App B
select seat
7B from reservations
where name is NULL

Phantom read
reservations
seat name ...
7C _____
Susan
7B
...
App A App B
select seat update reservations

7B from reservations set name = NULL
where name is NULL where seat = '7C'

Phantom read
reservations
seat name ...
7C
7B
...
App A App B


Phantom read
reservations
seat name ...
7C
7B
...
App A App B

...
select seat
from reservations
where name is NULL

Phantom read
reservations
seat name ...
7C
7B
...
App A App B

...
select seat
7C
from reservations
7B where name is NULL

Phantom read
reservations
seat name ...
7C
7B
...
App A App B

... The same SELECT (read) returns a

select seat different result: More rows (phantom
7C rows, in this case '7C', is shown)
from
7B reservations
where name is NULL This is a phantom read

Isolation levels
• “Policies” to control when locks are taken

• DB2 provides different levels of protection to isolate data
• Uncommitted Read (UR)
• Cursor Stability (CS)
• Currently committed (CC)
• Read Stability (RS)
• Repeatable Read (RR)

Setting the isolation levels
• Isolation level can be specified at many levels
• Session (application),
• Connection,
• Statement
• For statement level, use the WITH {RR, RS, CS, UR} clause:
SELECT COUNT(*) FROM tab1 WITH UR
• For embedded SQL, the level is set at bind time

• For dynamic SQL, the level is set at run time

Comparing isolation levels

Cursor stability with currently committed (CC) semantics
• Cursor stability with currently committed semantics is the default
isolation level
• Use cur_commit db cfg parameter to enable/disable
• Avoids timeouts and deadlocks
Cursor Cursor stability with

stability currently
committed

Cursor stability without currently committed
reservations
App A seat name ...
App B 7C Susan
7B
...
Cursor stability with currently committed (Default behavior)

reservations
App A seat name ...
App B 7C Susan
7B
...

reservations
App A seat name ...
update
App B 7C Susan
reservations X
set name = 'John' 7B
where seat = ...
'7C'

reservations
App A seat name ...
App B 7C Susan
7B
...

reservations
App A seat name ...
update
App B 7C Susan
John
reservations X
where seat = ...
'7C'

reservations
App A seat name ...
App B 7C Susan
7B
...

reservations
App A seat name ...
update
App B 7C select name
Susan
John S
reservations X from reservations
where seat =
where seat = '7C'
'7C' ...

reservations
App A seat name ...
App B 7C Susan
7B
...

reservations
Lock
App A seat name ... App B
update 7C Wait select name
Susan
John S
where seat =
where seat = '7C'
'7C' ...

reservations
App A seat name ...
App B 7C Susan
7B
...

reservations
Lock
update Wait select name
7C John
Susan S
where seat =
where seat = ... '7C'
'7C'
App B hangs until App A commits or rolls back which releases X lock

reservations
App A seat name ...
App B 7C Susan
7B
...

reservations
Lock
7C John
Susan S
where seat =
'7C'

reservations
App A seat name ...
update
App B 7C Susan
reservations X
where seat = ...
'7C'
reservations
Lock
7C John
Susan S
where seat =
'7C'

reservations
App A seat name ...
update
App B 7C
X
John
Susa
reservations n
where seat = ...
'7C'
reservations
Lock
7C John
Susan S
where seat =
'7C'

reservations
App A seat name ...
update
App B 7C select name
X
John
Susa S
reservations n from reservations
where seat =
where seat = '7C'
'7C' ...
reservations
Lock
7C John
Susan S
where seat =
'7C'

reservations
update select name
7C John
Susa S
7B n
set name = 'John' where seat =
'7C' App B retrieves currently committed value of 'Susan'
Comparing and choosing an isolation level
Isolation Level Lost Dirty Non-repeatable Phantom Read

update Read
Read
Repeatable Read (RR) - - - -
ReadStability (RS) - - - Possible
Cursor Stability (CS) - - Possible Possible
Uncommitted Read (UR) - Possible Possible Possible
Application Type High data stability High data stability not

required required
Read-write transactions RS CS
Read-only transactions RS or RR UR

Agenda
• Transactions
• Lock Wait
• Deadlocks

Lock wait
■ By default, an application waits indefinitely to obtain any
needed locks
■ LOCKTIMEOUT (db cfg):
– Specifies the number of seconds to wait for a lock
– Default value is -1 or infinite wait
■ Example: (Same as when using isolation CS without CC):
reservations
7C Susan
7B
...

Lock wait
needed locks
reservations
update 7C Susan
reservations X
where seat = ...
'7C'

Lock wait
needed locks
reservations
update 7C Susa
John
reservations X
7B n
set name = 'John'
where seat = ...
'7C'

Lock wait
needed locks
reservations
update 7C select name
Susa
John S
7B n
where seat = '7C'
'7C' ...

Lock wait
needed locks
reservations
Lock
update 7C
Wait
select name
Susa
John S
7B n
where seat = '7C'
'7C' ...

Lock wait
needed locks
reservations
Lock
update 7C John
Wait
select name
Susa S
7B n
where seat = '7C'
'7C' ...
App B waits “LOCKTIMEOUT” seconds to get 'S' lock on first row
Agenda
• Transactions
• Lock Wait
• Deadlocks

Deadlocks
■ Occurs when two or more applications wait indefinitely for a resource
■ Each application is holding a resource that the other needs
■ Waiting is never resolved
■ In the example, assume we are using isolation CS without CC
reservations
App A seat name ...
App B 7C Susan
7B
...
8E Raul
9F Jin

Deadlocks
reservations
App A seat name ...
update
App B 7C Susan
reservations X
where seat = ...
'7C' 8E Raul
9F Jin

Deadlocks
reservations
App A seat name ...
update
App B 7C Susan
John
reservations X
where seat = ...
'7C' 8E Raul
9F Jin

Deadlocks
reservations
App A seat name ...
update
App B update
7C Susan
John
reservations X reservations
set name = 'John' 7B set name = 'Sue'
where seat = where seat =
'7C' ... '9F'
8E Raul
X
9F Jin

Deadlocks
reservations
App A seat name ...
update
App B update
7C Susan
John
'7C' ... '9F'
8E Raul
Jin X
9F Sue

Deadlocks
reservations
App A seat name ...
update
App B update
7C Susan
John
'7C' ... '9F'
... 8E Raul
S Jin X
select name 9F Sue
from reservations
where seat =
'9F' 71 © 2011 IBM Corporation
Deadlocks
reservations
App A seat name ...
update
App B update
7C Susan
John
'7C' ... '9F'
... 8E Raul
S Jin X
select name Lock 9F Sue
from reservations
Wait
where seat =
'9F' 72 © 2011 IBM Corporation
Deadlocks
reservations
App A seat name ...
update
App B update
7C Susan
John S
'7C' ... '9F'
... 8E Raul ...
S Jin X
select name Lock 9F Sue select name
from reservations from reservations
Wait
'9F' 73 '7C' © 2011 IBM Corporation
Deadlocks
reservations
seat name ...
App A Lock App B
update
update 7C Susan
John Wait
7B S
set name = 'John' set name = 'Sue'
'7C' ... '9F'
... 8E Raul ...
S Jin X
select name Lock 9F Sue select name
Wait
Deadlocks
reservations
App A seat name ... Lock App B
update update
7C Susan
John Wait
7B S
set name = 'John' set name = 'Sue'
where seat = ... where seat =
'7C' '9F'
8E Raul
... 9F Sue
Jin X ...
select name
S select name
Lock
Wait
where seat = Deadlo ck! where seat =
Deadlocks
■ Deadlocks are commonly caused by poor application

design
■ DB2 provides a deadlock detector
– Use DLCHKTIME (db cfg) to set the time interval for checking for
deadlocks
– When a deadlock is detected, DB2 uses an internal algorithm to pick

which transaction to roll back, and which one to continue.
– The transaction that is forced to roll back gets a SQL error. The
rollback causes all of its locks to be released

Thank you!

1.5 - Data Concurrency and Locking

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1.5 - Data Concurrency and Locking

Uploaded by

Copyright:

Available Formats

Data concurrency and locking

IBM Information Management Cloud Computing Center of Competence

2 © 2011 IBM Corporation

3 © 2011 IBM Corporation

4 © 2011 IBM Corporation

Your bank account Your Mom’s bank account

Balance = $1000 Balance = $200

Transfer $100 from your account to your Mom’s account:

5 © 2011 IBM Corporation

• One or more SQL statements altogether treated as one

6 © 2011 IBM Corporation

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

9 © 2011 IBM Corporation

• Locks are acquired automatically as needed to support a

• COMMIT and ROLLBACK statements release all locks

• Two basic types of locks:

11 © 2011 IBM Corporation

12 © 2011 IBM Corporation

13 © 2011 IBM Corporation

14 © 2011 IBM Corporation

15 © 2011 IBM Corporation

update reservations update reservations

16 © 2011 IBM Corporation

update reservations update reservations

17 © 2011 IBM Corporation

update reservations update reservations

18 © 2011 IBM Corporation

19 © 2011 IBM Corporation

20 © 2011 IBM Corporation

21 © 2011 IBM Corporation

22 © 2011 IBM Corporation

23 © 2011 IBM Corporation

24 © 2011 IBM Corporation

25 © 2011 IBM Corporation

26 © 2011 IBM Corporation

27 © 2011 IBM Corporation

28 © 2011 IBM Corporation

29 © 2011 IBM Corporation

7C select seat update reservations

30 © 2011 IBM Corporation

7C select seat update reservations

31 © 2011 IBM Corporation

7C select seat update reservations

32 © 2011 IBM Corporation

7C select seat update reservations

33 © 2011 IBM Corporation

7C select seat update reservations

34 © 2011 IBM Corporation

35 © 2011 IBM Corporation

36 © 2011 IBM Corporation

37 © 2011 IBM Corporation

select seat update reservations

38 © 2011 IBM Corporation

select seat update reservations

39 © 2011 IBM Corporation

select seat update reservations

40 © 2011 IBM Corporation

select seat update reservations

41 © 2011 IBM Corporation

select seat update reservations

... The same SELECT (read) returns a

42 © 2011 IBM Corporation

• “Policies” to control when locks are taken