Browse Prior Art Database

Lock Escalation Enhancement

IP.com Disclosure Number: IPCOM000014475D
Original Publication Date: 2001-Jul-12
Included in the Prior Art Database: 2003-Jun-19
Document File: 1 page(s) / 36K

Publishing Venue

IBM

Abstract

The proposed solution introduces a new way of triggering lock escalations. This results in enabling applications to hold many more locks and, at the same time eliminates the problem of exhausting the lock table. Most database management systems use some sort of lock manager as a component that serializes accesses to the database shared resources. The lock manager maintains a list (often called 'lock table') where the locked resources are registered with their attributes such as lock holders, waiters, compatibility characteristics etc. Other components of the database system make requests to the lock manager when they need access to the shared resources and the lock manager grants, suspends or rejects these requests. The lock table is finite in size. Therefore there is a limit of how many locks can be recorded in it. Consequently, there is a limit on how many locks one database system can hold concurrently. Once that limit is reached no further processing is possible until some of the locks are released by the database system (which is in most cases controlled by the commit frequency of the applications running in the system). This is a major scalability constraint and there is already a mechanism in place that tries to reduce the exposure of experiencing this critical situation. It is based on escalating low level locks, i.e. row and block (also called 'page') locks. Escalation is the process of replacing a number of low level locks with a single lock with a much larger footprint (e.g. whole table). Note that the lock escalation is not a welcome event and should be treated only as a necessary measure to prevent a greater problem (the entire system suspends in a case where the lock table is exhausted). The current way of triggering the escalation is checking if a tablespace accumulated more locks than a user-specified threshold, given in the number of locks that can be concurrently held on that particular tablespace. This causes a problem: it is difficult and sometimes impossible to define the appropriate threshold value. If it is too small, the lock escalation occurs too often. If it is too high, the combined number of locks held across a number of tablespaces might be enough to exhaust the lock table without triggering the individual tablespace escalations before that.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 1

Lock Escalation Enhancement

The proposed solution introduces a new way of triggering lock escalations. This results in enabling applications to hold many more locks and, at the same time eliminates the problem of exhausting the lock table.

Most database management systems use some sort of lock manager as a component that serializes accesses to the database shared resources. The lock manager maintains a list (often called 'lock table') where the locked resources are registered with their attributes such as lock holders, waiters, compatibility characteristics etc. Other components of the database system make requests to the lock manager when they need access to the shared resources and the lock manager grants, suspends or rejects these requests.

The lock table is finite in size. Therefore there is a limit of how many locks can be recorded in it. Consequently, there is a limit on how many locks one database system can hold concurrently. Once that limit is reached no further processing is possible until some of the locks are released by the database system (which is in most cases controlled by the commit frequency of the applications running in the system). This is a major scalability constraint and there is already a mechanism in place that tries to reduce the exposure of experiencing this critical situation. It is based on escalating low level locks, i.e. row and block (also called 'page') locks. Escalation is the process of replacing a number of low level locks with a single lock with a much larger footprint (e.g. whole table). Note that the lock escalation is not a welcome event and should be treated only as a necessary measure to prevent a greater problem (the ent...