DB2 Locks and Isolation Levels

24/06/2010

BFS/BFS4/SIX SIS Ag

Author: Sanchari Pal

[email protected]
HU UH

TCS Public
1 Introduction
U0B

Lock is a DB2 mechanism that can provide concurrency and consistency. It controls access to
data pages and table spaces. It is used to associate a data resource with a single transaction, with
the purpose of controlling how other transactions interact with that resource while it is
associated with the owning transaction. Based on SQL statements DB2 provides different types
of locks.
They are -
1) 1. Shared Lock (S)
2) 2. Update Lock (U)
3) 3. Exclusive Lock (X)

Shared Lock
It allows two or more program to read simultaneously but not changed the lock space. Used for
read operations that does not change or update data.

Update Lock
It allows other transactions to read or acquire shared locks on the space. It is used on resources
that can be updated. It prevents deadlock that occurs when multiple sessions are reading,
locking and potentially updating resources later.

Exclusive Lock
It bars all other users from accessing the space. It is used for data modification operations, such
as Insert, Update or Delete. It ensures that multiple updates cannot be made to the same
resource at the same time.

2 Concurrency and Locks

1B

Concurrency is the ability of more than one application process to access the same data at the
same time.
Concurrency must be controlled to prevent lost updates and undesirable effects such as
unrepeatable reads and access to uncommitted data.

For Example -

Without concurrency control, two processes may read the same row from the database at the
same time and if both the processes update the database, either of the updates can be lost.

Consider the following scenario -

1. Transaction A reads row 1.

Internal Use 2
 2. Transaction B reads row 1.
3. Transaction A updated row 1.
4. Transaction B updates row 1, overlaying changes applied by transaction A.

In the above scenario, updates performed by Transaction A are lost.

Also, while updating, if one of the process updates the database and other uses the values
before it was committed, the calculations may happen on uncommitted data and hence will be
incorrect.

Consider the following scenario -

1. Transaction A inserts row 1 without committing.

2. Transaction B reads row 1.
3. Transaction B rolls back row 1.
4. Transaction A now has a row that physically does not exist.

If a process reads database and goes to process other SQL requests and later in the flow it reads
the database again, it should find the same values it read sometime. But without concurrency
control, the database might have been updated between the two operations.

When a transaction reads the same query multiple times and results are not the same each time,
same data is read again.

Consider the following scenario -

1. Transaction A reads a row of data.

2. Transaction B modifies this row and commits.
3. Transaction A re-reads the same row and sets back different data values.

When a row of data matches the first time but does not match subsequent times, phantoms
occurs.

Consider the following scenario -

1. Transaction A reads two rows based on a Query A where clause.

2. Transaction B inserts a new row that happens to fall under Transaction A Query A's
where clause.
3. Transaction A runs Query A again and gets back three rows.

To prevent all such undesirable situations, DB2 uses isolation and lock to control concurrency.

Internal Use 3
3 Using Locks
2B

A lock associates a DB2 resource with an application process in a way that affects how other
processes can access the same resource. DB2 uses locks to ensure that no process accesses data
that has been changed, but not yet committed, by another process

3.1 Disadvantages of Locks

3B

Locks might cause situations that degrade DB2 performance raising conditions such as
suspension, time out and deadlock.

Suspension
An application process is suspended when it requests a lock that is already held by another
application process and cannot be shared. The suspended process temporarily stops running.

Time Out
An application process is said to time out when it is terminated because it has been suspended
for longer than a preset interval.

Deadlock
A deadlock occurs when two or more application processes each hold locks on resources that
the others need and without which they cannot proceed. Mutual waiting for the other
application to release a lock on held data leads to deadlock.

A deadlock is illustrated in the following diagram –

Internal Use 4
3.2 Minimizing Deadlocks
4B

Deadlocks can be reduced by

• Issuing COMMIT statements at the right frequency.

• Choosing the appropriate isolation levels.
• Specifying the FOR FETCH ONLY clause in the Select statement
• Releasing read locks using the WITH RELEASE option of the CLOSE CURSOR statement, if
acceptable.

3.3 Aspects of transaction locks

5B

Different factors such as size, duration, modes and object of transaction lock can explain the
reason for suspension, time out and deadlocks.

• Lock Size Æ The size of a lock on data in a table describes the amount of data that is
controlled by the lock. DB2 uses locks of the following sizes
o Table space
o Table
o Partition
o Page
o Row
** A table space lock (the largest size) controls the most data, all the data in an entire table
space. A page or row lock controls only the data in a single page or row.

• Duration Æ A table space lock (the largest size) controls the most data, all the data in an
entire table space. A page or row lock controls only the data in a single page or row.

• Modes Æ The mode of a lock tells what access to the locked object is permitted to the
lock owner and to any concurrent processes.

** When a page or row is locked, the table, partition, or table space containing it is also locked.

In that case, the table, partition, or table space lock has one of the intent modes: IS, IX, or SIX. The
modes S, U, and X of table, partition, and table space locks are sometimes called gross modes.

• Object Æ The object of a lock is the resource that is being locked.

Internal Use 5
 3.4 Choosing Locks
6B

• Locks acquired for SQL statement Æ The lock acquired is not always constant
throughout the execution. DB2 can change the locks. The locks acquired for a particular
SQL statement depend on the following factors

o The type of processing being performed.

o The value of Locksize for the target table.
o The isolation level of the plan, package or statement.
o The method of access to data.
o The attributes of the application and target tables

• Lock Promotion Æ Lock promotion is the action of exchanging one lock on a resource
for a more restrictive lock on the same resource, held by the same application process.

When promoting the lock, DB2 first waits until any incompatible locks held by other
processes are released. When locks are promoted, they are promoted in the direction of
increasing control over resources.

• Lock EscalationsÆ Lock escalation is the act of releasing a large number of page, row,
locks ,held by an application process on a single table or table space, to acquire a table
or table space lock, or a set of partition locks, of mode S or X instead.

Lock escalation balances concurrency with performance by using page or row locks
while a process accesses relatively few pages or rows, and then changing to table space,
table, or partition locks when the process accesses many. When it occurs, lock escalation
varies by table space, depending on the values of LOCKSIZE and LOCKMAX. Lock
escalation is suspended during the execution of SQL statements for ALTER, CREATE,
DROP, GRANT, and REVOKE.

3.5 Tuning Locks

7B

Following options can be used for tuning locks-

• In Internal resource lock manager (IRLM), by specifying some options DB2 can be
controlled.

• Installation options determine the duration it takes DB2 to identify that a process is
timed out or deadlocked.

• Bind options determine when an application process acquires and releases its locks.

Internal Use 6
Following points to be considered while tuning for concurrency and data integrity

• Either the entire table is locked or its not locked, specific rows in a table cannot be
locked.

• Create small units of work with frequent COMMIT statements to promote concurrent
access of data by many users. Include COMMIT statements when the data you have
changed is consistent. When a COMMIT is issued, all locks are released except those
related to open cursors

• An appropriate isolation level should be specified.

• Close the cursors to release the locks that they hold.

4 Isolation Levels
8B

An isolation level specifies how much one transaction is isolated from other transactions in a
multiple-connection environment. It determines the duration of lock over a page.

Following are the various types of isolation -

• Repeatable Read - Locks the table within a unit of work. An application can retrieve and
operate on rows in the table as many times as needed. However, the entire table is
locked, not just the rows that are retrieved. Until the unit of work completes, no other
application can update, delete, or insert a row that would affect the table.

• Read Stability -It locks the entire table thereby avoiding lost updates, access to
uncommitted data.

• Cursor Stability- Lock is retained until the cursor moves from one record in the page to
the next record in another page.

• Uncommitted Read -An application can access some uncommitted changes of other
transactions: tables and indexes that are being created or dropped by other transactions
are not available while the transaction is processing. Any other changes can be read
before they are committed or rolled back.

** The ISOLATION (UR) or uncommitted read option allows an application to read while
acquiring few locks, at the risk of reading uncommitted data. UR isolation applies only to
read-only operations: SELECT, SELECT INTO, or FETCH from a read-only result table.

Internal Use 7
 ISOLATION (UR) option cannot be used for the following types of statements:

• INSERT, UPDATE, DELETE MERGE

• SELECT from INSERT, UPDATE, DELETE, MERGE

• Any cursor defined with a FOR UPDATE Clause

4.1 Choosing Isolation levels

9B

Isolation levels should be decided on which concurrency problems are to be prevented in the
application.

• Uncommitted Read isolation level is used only if read only tables are queried or on using
Select statements, getting uncommitted data from concurrent applications is
acceptable.

• Cursor Stability isolation level is used when maximum concurrency is expected while
seeing only committed data from concurrent applications.

• Read Stability isolation level is used when your application operates in a concurrent
environment i.e. only the qualified rows have to remain stable for the duration of the
unit of work.

• Repeatable Read isolation level is used if the changes to the result set are unacceptable.

** Uncommitted Read Isolation level provides the maximum concurrency whereas Repeatable
Read Isolation level provides the minimum concurrency.

Example -

//********************************************************************
//* BIND - BIND THE DB2 PACKAGE *
//********************************************************************
//BIND EXEC PGM=IKJEFT01,
// COND=(4,LT),
// REGION=4096K
//STEPLIB DD DISP=SHR,
// DSN=XXX4.DB2.XXXX.XXXXLOAD
//DBRMLIB DD DISP=SHR,
// DSN=DEV.COBOL1.DBRM(DB2PROG)
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSTSIN DD *
DSN SYSTEM (DEVDB )
BIND MEMBER (DB2PROG) -
PACKAGE (PACKG11) -
LIBRARY ('DEV.COBOL1.DBRM') –
ACTION (REP) -
ISOLATION (CS) -

Internal Use 8
 VALIDATE (BIND)-
RELEASE (COMMIT) -
OWNER (COBOL1) -
QUALIFIER (DEVQUALI)
END
/*

4.2 Lock Contention

10B

To maintain the integrity of DB2 objects, only one object can be accessed at a time. Lock
contention happens if several objects are required by contending application processes
simultaneously.

4.3 Intent Lock

1B

Intent locks are used to protect placing a shared lock or exclusive lock on a resource lower in the
lock hierarchy. It prevents other transactions from modifying the higher level resource in a way
that would invalidate the lock at lower level. Also it improves the efficiency of the Database
engine in detecting lock conflicts.

Intent Lock includes

• Intent Shared (IS) – Protects requested or acquired shared locks on some resources lower
in hierarchy

• Intent Exclusive (IX) – Protects requested or acquired exclusive locks on some resources
in lower level. Being a super set of Intent Shared lock, it also protects requesting shared
locks on lower level resources.

• Shared with Intent Exclusive (SIX) – Protects requested or acquired shared lock on all
resources lower in the hierarchy and intent exclusive locks on some of the lower level
resources.

• Intent Update (IU) – Protects requested or acquired update locks on all resources lower
in the hierarchy. IU locks are used only on page resources. IU locks are converted into IX
locks if an update operation takes place.

• Shared Intent Update (SIU) – A combination of shared and Intent update locks, as a result
of acquiring these locks separately and simultaneously holding both locks.

• Update Intent Exclusive (UIX) – A combination of Update and Intent exclusive locks, as a
result of acquiring these locks separately and simultaneously holding both locks.

Internal Use 9