Concurrency and locking Pertemuan 8 Matakuliah: T0413 Tahun: 2009.

Concurrency and lockingPertemuan 8

Matakuliah : T0413Tahun : 2009

Bina Nusantara University 3

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 Savings account - Credit $100 to Checking account


ID Name Age

3 Peter 33

5 John 23

22 Mary 22

35 Ann 55

App A

App B

App C

App D

Concurrency overview


ID Name Age

3 Peter 33

5 John 23

22 Mary 22

35 Ann 55

App A

App B

App C

App D

Locking overview


Concurrency

• DB2 was designed as a multi-user database

• Access to data must be coordinated properly and transparently using a mechanism to ensure data integrity and consistency

• Without some form of concurrency control, the following problems may be encountered

– Lost update – Uncommitted read– Non-repeatable read– Phantom read


Lost UpdateReservationsFlight Seat P-Name

512

512

7C

7B...

..

. ...

512 5127C Instruct Manager... ...

?

7C

Update Reservations Set P-name = 'Instruct' Where Flight = 512 and Seat = '7C' and P_name is NULL

Update Reservations Set P-name = 'Manager' Where Flight = 512 and Seat = '7C' and P_Name is NULL


Uncommitted ReadReservations

Flight Seat P_Name

512

512

512

7C

7B

7C Instruct

1

3

Update Reservations Set P-name = 'Instruct' Where Flight = 512 and Seat = '7C' and P_Name is NULL

Roll back

2

4

Select seat From Reservations Where P-name is NULL

Incorrect results set

... ...


Non-repeatable Read

FLIGHT SEAT NAME DESTINATION ORIGIN

512

814

134

7B

8A

1C

DENVER

SAN JOSE

HONOLULU

DALLAS

DENVER

SAN JOSE

....

Book a flight from Dallas to Honolulu

....

....

....

....


Phantom ReadReservationsFlight Seat P-name

512

512

512

7B

7A

7B

1 Update Reservations Set P-name = 'NULL' Where Flight = 512 and Seat = '7A' and P-name = 'Susan Liu '

2Select seat From Reservations Where P-name is NULL

Repeat 1 now seat 7A is available

... ...Susan Liu

3


Locking• DB2 uses locking to maintain data integrity

• Locks are acquired automatically as needed to support a transaction and are released when the transaction terminates (COMMIT/ROLLBACK)

• Locks can be acquired on tables or rows• 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


Isolation Levels

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

• Isolation level can be specified at many levels– Session (application). Defaults to CS– Connection– Statement

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


Comparing isolation levels


Isolation Levels – Uncommitted Read•Uncommitted Read is also known as DIRTY READ

– Lowest level of isolation– Provides highest degree of concurrency

• No row locks are obtained on read operations– unless other application attempts to drop or alter table

• Update operations act as if using Cursor Stability

•Possible Situations– Uncommitted Read– Non-repeatable Read– Phantom Read

•Situations Prevented– Loss of Update


Isolation Levels – Cursor Stability• Cursor Stability is the default isolation level

– Minimal degree of locking– Locks the "current" row of a cursor– If the row is only read

• the lock is held until a new row is fetched or the unit of work is terminated

– If the row is updated • the lock is held until the unit of work is terminated

• Possible Situations– Non-repeatable Read– Phantom Read

• Prevented Situations– Loss of Update– Uncommitted Read


Isolation Levels – Read Stability• Locks all the rows an application retrieves within

a unit of work– For a given cursor, it locks all rows that qualify for the result

set– Moderate degree of locking

• Possible Situations– Phantom Read

• Prevented Situations– Loss of Update– Uncommitted Read– Non-repeatable Read


Isolation Levels – Repeatable Read• Highest isolation level, least concurrency

– Same query issued by the application more than once in a unit of work will give the same result each time

– High degree of locking– Locks held on all rows processed to build the result set

• i.e. rows not necessarily in the final result set may be locked

– No other application can update, delete, or insert a row that would affect the result set until the unit of work completes

• Possible Situations– none

• Prevented Situations– Loss of Update– Uncommitted Read– Non-repeatable Read– Phantom Read


Comparison of Isolation Level Terminolgy

DB2 .NET JDBC

Uncommitted Read (UR)

ReadUncommitted

TRANSACTION_READ_UNCOMMITTED

Cursor Stability (CS)

ReadCommitted TRANSACTION_READ_COMMITTED

Read Stability (RS)

RepeatableRead TRANSACTION_REPEATABLE_READ

Repeatable Read (RR)

Serializable TRANSACTION_SERIALIZABLE


Statement Level IsolationSELECT ... WITH {UR | CS | RS | RR}

UR = Uncommitted ReadCS = Cursor StabilityRS = Read StabilityRR = Repeatable Read

• Example Scenario: – Application needs to get a "rough" count of how

many rows are in table. Performance is of utmost importance. Cursor Stability isolation level is required with the exception of one SQL statement:

SELECT COUNT(*) FROM tab1 WITH UR


lockescalation

table

multiplerowlocks

tablelock

table

table

Lock Escalation


Lock Escalation

• When optimizer thinks it is better to have one lock on the entire table, rather than multiple row locks

• Database configuration parameters that affect lock escalation:

– LOCKLIST – the amount of memory (4k pages) to manage locks for all connected applications

• Default is 50 * 4K pages on Windows

– MAXLOCKS –Max percentage of the entire lock list that a single application can use up

• Default is 22 percent


Lock Escalation (continued)• If the default values are used, lock escalation occurs

when a single application requires more than 44K of lock memory

• If lock escalation, increase the value of LOCKLIST and MAXLOCKS

• Avoid lock escalations: Performance bottleneck• Check the DB2 diagnostic log file (db2diag.log). The

location is shown below. On Windows XP, 2003:– C:\Documents and Settings\All Users\Application Data\IBM\DB2\DB2COPY1\<instance name>

On Windows Vista:– ProgramData\IBM\DB2\ On Linux/UNIX:– INSTHOME/sqllib/db2dump (INSTHOME is the home directory of the instance owner)


2007-01-02-23.04.43.699000 Instance:DB2 Node:000PID:984(db2syscs.exe) TID:1720 Appid:*LOCAL.DB2.011003030417data_management sqldEscalateLocks Probe:1 Database:SAMPLE

-- Start Table Lock Escalation. -- Lock Count, Target : 28, 147570 6461 7465 2065 6d70 6c6f 7965 6520 update employee7365 7420 6669 7273 746e 6d65 3d27 6162 set firstnme='ab6327 c'

2007-01-02-23.04.43.699001 Instance:DB2 Node:000PID:984(db2syscs.exe) TID:1720 Appid:*LOCAL.DB2.011003030417data_management sqldEscalateLocks Probe:2 Database:SAMPLE

-- Lock Count, Target : 28, 14 -- Table (ID) Name : (2;5) ADMINISTRATOR.EMPLOYEE -- Locks, Request Type : 25, X -- Result (0 = success): 0

Lock Escalation indication in the db2diag.log


View locks currently held by an application

UPDATE MONITOR SWITCHES USING LOCK ON

GET SNAPSHOT FOR LOCKS FOR APPLICATION AGENT ID <handle>

Application Lock Snapshot

Snapshot timestamp = 11-05-2002 00:09:08.672586

Application handle = 9Application ID = *LOCAL.DB2.00B9C5050843Sequence number = 0001Application name = db2bp.exeAuthorization ID = ADMINISTRATORApplication status = UOW WaitingStatus change time = Not CollectedApplication code page = 1252Locks held = 4Total wait time (ms) = 0

List Of Locks Lock Name = 0x05000700048001000000000052 Lock Attributes = 0x00000000 Release Flags = 0x40000000 Lock Count = 255 Hold Count = 0 Lock Object Name = 98308 Object Type = Row Tablespace Name = TEST4K Table Schema = ADMINISTRATOR Table Name = T2 Mode = X

Lock Snapshot


Lock Wait

• By default, an application waits indefinitely to obtain any needed locks

• LOCKTIMEOUT (db cfg):– Change to specify the number of seconds to wait for a lock– Default value is -1 or infinite wait

• A database connection also has a user-definable CURRENT LOCK TIMEOUT register– By default it inherits its value from the LOCKTIMEOUT

parameter– Use the SET LOCK TIMEOUT statement to change its value– Once it is set for a connection, it persists across transactions– e.g. SET LOCK TIMEOUT=WAIT n


Deadlock Causes and Detection

MILKUSER A

USER B

RAISINBRAN

within a UNIT OF WORK (UOW) INSERT CEREAL AND MILK into BOWL


Deadlock Settings• Deadlocks are an application design issue most of the

time

• DLCHKTIME (db cfg) sets the time interval for checking for deadlocks– It defines the frequency that the database manager checks for

deadlocks among all the applications connected to a database

• If you are experiencing many deadlocks, you should re-examine your existing transactions and see if any re-structuring is possible


Best Practices• Keep transactions as short as possible

– Issue frequent COMMIT statements – even for read-only transactions• Log transaction information only when required

– Purge data quick using:• ALTER TABLE ACTIVATE NOT LOGGED INITIALLY WITH EMPTY TABLE

– Perform data modifications in batches/groups• DELETE FROM ( SELECT * FROM tedwas.t1 WHERE c1 = …

FETCH FIRST 3000 ROWS ONLY )

– Use concurrency features in DB2 data movement tools

• Set the database level LOCKTIMEOUT parameter (usually between 30-120 seconds)– Can also use session-based lock timeout

• Do not retrieve more data than is required– Use the FETCH FIRST n ROWS ONLY clause in SELECT statements

Concurrency and locking Pertemuan 8 Matakuliah: T0413 Tahun: 2009.

Documents

Transcript of Concurrency and locking Pertemuan 8 Matakuliah: T0413 Tahun: 2009.