When an SQL statement in a transaction first accesses a tablespace with a page or row level lock, DB2 first takes a particular type of lock, called an intent lock, at the table and tablespace level for a segmented tablespace or tablespace level for a non-segmented tablespace. It later takes an S, U, or X lock against the page or row on which the data reside as SQL is executed. In a sense, the intent locks act as traffic signals that regulate the use of page and row level locks, and signal to concurrent transactions the type of access the pages or rows are undergoing. This avoids using resources necessary to determine if the required page or row can be selected on updated.
Intent locking reduces the processing needed to manage the locks, while allowing a high degree of compatibility among concurrent locks. For example, if a given transaction needs the data it is about to read to remain unchanged, DB2 can take a share lock against the table or tablespace, which allows subsequent transactions to read but not change the data. The transaction must also be sure, however, that no changes are underway before it takes the S lock. That is where the intent lock comes in. For any X lock on a page or row in the tablespace, which would indicate an imminent change, DB2 will have taken an intent lock on the table or tablespace.