Granularity of Locks

Hierarchical lockable units:

assume set of resources to be locked is organized in a hierarchy, e.g. (database, areas, files, records) as a simple hierarchy. Each node of hierarchy can be locked, and in doing so, one implicity locks all of that node's descendants. There is shared access (S, shared-read access) and exclusive access (X, exclusive read/write access).
In order to lock a subtree rooted at node R in S or X, one must prevent others from obtaining incompatible locks on any ancestor of R. A new mode, "intention mode" is introduced to do this - all ancestors of a node are tagged with intention mode before the node itself is locked. Summary of modes:
null (NL): no access
intention-share (IS): allows requestor to lock descendant nodes in S or IS mode. (does no implicit locking)
intention-exclusive (IX): allows requestor to explicitly lock descendants in X, S, SIX, IX, or IS mode. (does no implicit locking)
share (S): access to node and all descendants without setting further locks. (implicitly sets S locks on all descendants)
share and intention exclusive (SIX): implicitly locks all descendants of node in share mode and allows requestor to explicitly lock descendant nodes in X, SIX, or IX mode. (for finer grained locking)
exclusive (X): exclusive access to node and all descendants. (implicitly sets X locks on all descendants)

To request a node,
before requesting S or IS on node, all ancestor nodes must be held in IX or IS mode.
before requesting X, SIX, or IX on node, all ancestors must be held in SIX or IX mode.
locks should be released either at end of transaction (in any order), or in leaf to root order in the middle of a transaction.

Source from: http://swig.stanford.edu/pub/summaries/database/locks.html