Intention lock - Ciallo Wiki

1 Introduction to Intention Locking

1.1 Motivation and problem it solves

In shared-resource systems, correctness often depends on preventing conflicting operations from interfering with each other. When data is organized hierarchically—such as tables containing pages, and pages containing rows—transactions typically lock at different levels of detail. The central difficulty is that determining whether a future fine-grained lock request conflicts with already-held locks becomes expensive if the lock manager must inspect many lower-level locks. Intention locking addresses this by letting a transaction “declare” its upcoming plan: it acquires an intention lock on a higher level to indicate that it will later obtain specific lower-level locks under that parent. This enables faster, simpler conflict detection.

1.2 Hierarchical locking model

A hierarchical locking model groups resources into levels (for example: database → table → page → row, or index → page → record). Locks at a higher level provide coarse control, while locks at lower levels provide targeted protection. The key design idea is that a lock on a parent resource represents a relationship to locks on its descendants. Intention locks are those parent-level locks that communicate how the transaction intends to lock descendant resources.

1.3 Relationship to shared and exclusive locks

Most lock systems distinguish between shared (typically allowing concurrent reads) and exclusive (typically requiring isolation for writes) modes. Intention locks are closely related to these notions, but they are not themselves the final protection for data at the leaf level. Instead, they indicate an intent to later request shared or exclusive locks on descendants. In this way, higher-level intention locks help the system anticipate conflicts with current shared/exclusive locks held by other transactions.

2 Lock Compatibility and Modes

2.1 Common lock intentions (e.g., intent-shared, intent-exclusive)

A common set of intention lock modes includes:

Intent-shared (IS): the transaction plans to obtain shared locks on descendant resources.
Intent-exclusive (IX): the transaction plans to obtain exclusive locks on descendant resources.

In many designs, these intentions are refined further (or defined alongside additional modes) so that compatibility checks can reason about how parent locks interact with other transactions’ parent and descendant locks.

2.2 Compatibility matrix basics

A compatibility matrix defines which lock modes can coexist on the same resource. In an intention-lock scheme, IS and IX are typically compatible with certain other modes because they do not grant immediate permission to read or write the entire resource; they merely announce future locking on sub-resources. Conversely, an exclusive lock at a higher level will generally conflict with intention locks because it blocks descendant locking. The precise matrix varies by implementation, but the qualitative property remains: intention modes are designed to be compatible with other intention and shared behaviors, while still preventing unsafe overlaps.

2.3 Why intention locks improve conflict detection

Without intention locks, if a transaction holds an exclusive lock on a table, the lock manager might need to examine many possible row or page locks to decide whether a new request is safe. With intention locks, the lock manager can often decide quickly at the parent level: if another transaction has declared it intends to lock descendants, and a conflicting table-level lock exists, the conflict is detected immediately. This reduces the overhead of scanning or tracking all fine-grained descendants for compatibility decisions.

3 Lock Acquisition Workflow

3.1 Escalation from high level to low level

A typical workflow acquires locks in a structured manner. Before locking a particular descendant (such as a row), the transaction first acquires an intention lock on each relevant ancestor. For example, to lock multiple rows within a table, the transaction might:

Acquire an IS or IX on the table depending on whether it will read-only or write.
Acquire locks on the pages that contain the target rows.
Acquire shared/exclusive locks on the individual rows.

This staged process ensures that parent-level compatibility checks are accurate before the system commits to finer-grained locks.

3.2 Ordering rules and deadlock considerations

Intention locking is usually paired with a lock ordering discipline. A common rule is that locks are acquired from higher to lower hierarchy levels (top-down). This limits cyclic wait patterns that cause deadlocks. While deadlocks can still occur under some schedules—especially when transactions interleave requests across different subtrees—consistent ordering with intention locks reduces the likelihood and simplifies reasoning about potential cycles.

3.3 Lock conversion and its implications

Some systems allow lock conversion, where a transaction changes the mode of an already-held lock rather than releasing and reacquiring it. Intention locks can be subject to conversion too; for instance, a transaction that initially declared it would take shared locks (IS) might later determine it needs exclusive locks (requiring promotion to IX) on an ancestor. Conversion must respect compatibility constraints with other transactions’ locks. Because conversion can fail or require waiting, it introduces additional complexity and may affect throughput if used frequently.

4 Interaction with Database Operations

4.1 Reading versus writing under intention locks

Intention locks coordinate how the system treats read and write operations. A read-oriented transaction often acquires shared locks on the specific leaf resources it accesses. It also sets appropriate intention modes on ancestors so that concurrent writers know which sub-resources will be targeted. In contrast, a write operation typically uses exclusive locks on affected descendants and therefore holds intention-exclusive locks on relevant ancestors. Even when the actual data access is at the leaf level, the ancestor intention locks guide global compatibility decisions.

4.2 Index operations and their locking patterns

Indexes naturally form hierarchical structures (often as trees or B-tree-like layouts with internal pages and leaf pages). Locking patterns for index operations commonly involve:

Intention locks on higher structural nodes (e.g., index/table level),
Additional locks on intermediate pages when traversing the structure,
Target locks on leaf records or key ranges.

These patterns allow concurrent scans and updates to coexist more safely because the lock manager can reason about conflicts using the declared intentions rather than relying solely on individual record locks.

4.3 Transaction isolation and visibility

Isolation levels determine how reads observe writes from other transactions. Intention locking itself is not the same mechanism as snapshot-based visibility, but it supports the correctness constraints required by isolation. By controlling which transactions can simultaneously hold conflicting locks on overlapping resources, intention locks help ensure that the isolation semantics can be upheld (for example, preventing writes from corrupting reads when exclusive access is required). In systems that also use multiversion approaches, intention locks may still be used for structural consistency or for protecting operations that cannot be handled purely through versioning.

5 Performance and Scalability Considerations

5.1 Reduced lock manager overhead

A major benefit is the reduction in bookkeeping. Instead of managing or checking every potential descendant lock when conflict might occur at the parent level, the lock manager can use the presence of intention locks to infer that descendants will be touched. This short-circuits expensive checks and allows compatibility tests to be performed with fewer lookups.

5.2 Contention characteristics in multi-level structures

Contention in hierarchical systems depends on how operations spread across the hierarchy. Without intention locking, contention can become “opaque”: even if two operations touch disjoint parts of a subtree, the lock manager may still perform heavy coordination at the parent level. With intention locks, the system more accurately models overlap based on declared intent, which tends to localize conflicts to the relevant parts of the hierarchy and improve effective concurrency.

5.3 Trade-offs versus simpler locking strategies

Intention locking introduces additional lock requests (ancestors must be locked first). This increases lock operations and metadata compared with strategies that lock only at the leaf level. Therefore, the performance advantage depends on workload characteristics: it is most beneficial when many fine-grained locks are requested and when conflict detection at higher levels can otherwise become costly. In workloads with very coarse access patterns or few locks per transaction, simpler strategies may be competitive or superior.

6 Implementation Notes

6.1 Lock table design and metadata

Implementations typically maintain a lock table keyed by resource identifiers at each hierarchy level. Each entry records which transaction holds which lock mode and, often, a queue order for waiting requests. Resource identity must be consistent across hierarchy levels so that intention locks on ancestors correctly relate to locks on descendants. Metadata may also include counts or lists for efficient handling of multiple lock holders.

6.2 Checking compatibility efficiently

Efficient compatibility checks often rely on:

Fast retrieval of current lock holders for a given resource,
Precomputed compatibility rules between lock modes,
Early exits when conflicts are obvious (e.g., when an exclusive mode at the parent level conflicts with an intention request).

Because intention locks are meant to enable parent-level decisions, the implementation should prioritize quick checks on ancestor resources to avoid descending traversal during conflict detection.

6.3 Failure modes and rollback behavior

If a transaction cannot acquire a required lock (because it waits and then times out, or is aborted under deadlock detection), the system must release all locks held by that transaction to restore safety. Rollback behavior must account for partially acquired intention locks: even if leaf locks were never granted, any ancestor intention locks obtained must be released. Correct cleanup is essential to prevent lingering lock states from blocking unrelated transactions.

7 Examples and Use Cases

7.1 Locking rows within a table

Suppose a transaction intends to update several rows in a table. It first acquires an intent-exclusive (IX) lock on the table, indicating it will request exclusive locks on rows. It then acquires exclusive locks on the pages that contain those rows (depending on the system’s granularity) and finally exclusive locks on each targeted row. Concurrent transactions that try to obtain incompatible table-level locks will be blocked early, while readers that only need shared access might still proceed if their locks are compatible with the declared intentions.

7.2 Locking pages within an index

Consider a transaction that performs range scanning in an index and may update entries within a subset. It acquires the appropriate intention lock on the index structure to signal it will lock descendants. While traversing, it takes locks on relevant index pages. When it reaches leaf records that fall within the update region, it requests shared or exclusive locks depending on whether it is merely inspecting or modifying. Intention locks at higher levels ensure the lock manager can quickly validate that these future page and record locks do not conflict with other transactions’ higher-level grants.

7.3 Preventing conflicts in concurrent scans and updates

A frequent scenario involves simultaneous read-only scans and write operations. Without intention locks, distinguishing safe concurrency would require more detailed tracking. With intention locking, a writer that plans exclusive operations on certain descendants marks its intent at ancestors, allowing readers to decide whether they can take shared locks without conflicting with the writer’s future leaf-level actions. As a result, the system avoids unnecessary blocking when the operations are confined to disjoint subtrees.

8 Common Pitfalls

8.1 Misunderstanding intention lock purpose

A common mistake is treating intention locks as if they directly protect leaf data. In reality, they are administrative signals at higher hierarchy levels. Confusing their role can lead to incorrect assumptions about what other transactions may safely do. Developers and database administrators should recognize that the actual protection of data integrity and visibility boundaries is provided by the leaf-level shared/exclusive locks, while intention locks enable correct and efficient coordination.

8.2 Over-locking and throughput degradation

Because intention locks require additional acquisition on ancestors, an overly fine-grained locking strategy can amplify overhead. If a transaction touches many small regions, it may accumulate numerous ancestor locks and lock manager work, reducing throughput. Systems and users must balance granularity choices against intention-lock costs, sometimes adjusting lock granularity or batching operations to reduce lock churn.

8.3 Inconsistent lock ordering leading to deadlocks

Even with intention locks, deadlocks can occur if a system violates hierarchical ordering rules. For example, if one transaction acquires a lock deep in one subtree and later requests an ancestor lock in a different order than another transaction, cycles can form. Ensuring a consistent top-down acquisition pattern and consistent rules for conversion are key safeguards.

9.1 Two-phase locking (2PL)

Two-phase locking is a broader correctness strategy in which transactions follow a disciplined pattern: they acquire locks and then enter a phase where they release locks without acquiring new ones. Intention locking often appears as part of practical implementations of 2PL in hierarchical resource environments, since the lock acquisition ordering and compatibility checks align with the structured nature of intention locks.

9.2 Granularity and lock escalation

Granularity determines whether locks are taken at the row, page, or table level. Lock escalation refers to increasing lock granularity during execution to reduce overhead (for example, promoting many row locks into a single table lock). Intention locks interact naturally with escalation because they already provide a mechanism for reasoning about parent-child relationships. However, escalation policies can still affect contention and performance if they broaden the scope of locks beyond what the workload requires.

9.3 Multiversion concurrency control (MVCC) overview (contrast)

Multiversion concurrency control aims to improve concurrency by allowing readers to view older versions of data while writers create new versions. MVCC reduces the need for blocking read operations, but it does not eliminate all forms of synchronization: structural changes, index maintenance, and certain write-write conflicts may still require locking. Compared with MVCC-only designs, intention locking remains a useful tool for coordinating hierarchical locking decisions even when some reads are handled via versions rather than strict blocking locks.