On October 23rd, 2014, we updated our
By continuing to use LinkedIn’s SlideShare service, you agree to the revised terms, so please take a few minutes to review them.
Locking can be implemented at various levels of the database.
The entire database could be locked. This would allow the processing of only one transaction at a time, and would probably provide unacceptably slow response time!
Table-level locking locks only the tables accessed by a transaction. This still leads to slow performance in many applications where users need to share access to the same tables.
Page-level locking locks individual blocks of data (called “pages”) as they are accessed. Other transactions may lock other pages of the same table for themselves.
Row-level locking allows two users to access different rows on the same page at the same time. This comes at a cost of increased overhead.
It is theoretically possible to lock at the data item level, but no commercial database offers this.
Shared and Exclusive Locks
A shared lock is used when a transaction is reading data, but not updating it. Another transaction can also acquire a shared lock on the same data at the same time.
An exclusive lock is used when a transaction is updating data. When a transaction has an exclusive lock, no other transaction can read or update the data.
DB2 also has an update lock, used when a transaction has indicated its intention of updating data (by selecting or fetching with the FOR UPDATE OF clause). Other transactions can acquire a shared lock (for reading the data only) until the update lock is promoted to an exclusive lock at the time the update actually occurs.
Transaction B Transaction A No No No Exclusive (X) No No Yes Update (U) No Yes Yes Shared (S) Exclusive Update Shared
A situation called a deadlock occurs when when two separate processes compete for resources held by one another.
Program 1 requests a lock for a data page held by Program 2 at the same time that Program 2 requests a lock for a data page held by Program 1. Without outside intervention, each will continue to wait for the other to complete. When DB2 detects a deadlock situation, it chooses one process to be the “victim” and denies that program’s lock request, returning a –911 SQL code. Setting a standard within an organization for the order in which tables are updated can reduce deadlock occurrences. Lock (wait) Deadlock Lock (wait) Update Table A (page 1) Update Table B (page 1) Intermediate processing Intermediate processing Lock established Lock established Update Table B (page 1) Update Table A (page 1) Program 2 Program 1
A timeout, caused by the unavailability of a resource, can be caused by data being locked by another process.
DB2 waits for a specified period of time, then returns a –911 SQL code to the waiting process. Lock is suspended, -911 returned to program 2 Timeout Lock (wait) Update Table B (page 1) Intermediate processing (if a program is not carefully designed, this can include a user’s coffee break!) Lock established Update Table A (page 1) Program 2 Program 1
LOCK TABLE table-name IN (SHARE, EXCLUSIVE) MODE
A program can explicitly lock an entire table, which may be advisable if it will repeatedly access the table.
Eliminates the overhead of page-by-page or row-by-row locking
Eliminates the possibility that another program will lock part of the data, causing it to wait
Eliminates the possibility of a deadlock forcing the program to start over again
The LOCK TABLE statement can be coded in a program to lock a table in shared or exclusive mode.
There is no UNLOCK TABLE statement. The table is unlocked when the transaction is ended by a commit or rollback.
In reality the locking techniques used by DB2 are much more complex than the concepts described here. The Database Administrator can improve performance by manually adjusting some settings called locking parameters . This is part of a process often called tuning the database.
Locksize. The DBA can specifiy locking at the table, page, or row level. In general, letting DB2 handle the level of locking is best, by specifying LOCKSIZE ANY.
Lock escalation. DB2 can automatically “escalate” locks, replacing many small locks with a single larger lock. (For example, replacing many page locks with a table lock.) The DBA has some control over when this is done.
Number of locks. The DBA can set the number of locks a transaction may have, raising it to encourage complex transactions or lowering it to encourage earlier lock escalation.
Lock timeout. The DBA can adjust the amount of time a process waits for a lock before timing out.
Guidelines for Locking
Limit the number of rows accessed by a program by coding predicates to filter unwanted rows. Doing so reduces the number of locks on pages containing rows that are accessed but not required.
Design update programs so the update is as close to the commit point as possible, reducing the time that locks are held. In an online application, make sure user intervention is not required to end a transaction.
Design all application programs to access tables in the same order. Doing so reduces the possibility of deadlock.
Consider what would be the appropriate isolation level for a program you are designing.
Avoid ambiguous cursors by specifying FOR READ ONLY or FOR UPDATE OF column-name .
Use the LOCK TABLE statement with caution.
Use caution when using the CURSOR WITH HOLD clause. This causes locks to be held across commits.
Guidelines for Isolation Level UR
In general, most DB2 applications are not candidates for “dirty reads”. It may be helpful when:
Access is required to a code table or look-up table, whose data doesn’t change often (like the school calendar table).
You know your program runs at a time when no other users are accessing the same data.
You are accessing read-only decision-support data.
Statistical processing is being performed on a large amount of data. A few uncommitted rows may not be statistically significant.
A table is used by a single user.
If you think a new process you are designing, or an existing process you are modifying, qualifies for isolation level UR, ask the DBAs!
Locks are used to control access to data as it is updated.
DB2 uses different types of locks at different levels of the database to protect data with the least delay to other processes.
DB2 “times out” a process that has waited for a lock past a specified amount of time.
DB2 breaks deadlocks by returning a –911 SQL code to one of the deadlocked processes.