Jump to content

Index locking: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Comps (talk | contribs)
→‎See also: Database stub; Concurrency control category
Comps (talk | contribs)
Ref added +
Line 3: Line 3:
In [[database]]s an ''[[Index (database)|index]]'' is a data structure, part of the database, utilized by a database system to effectively navigate access to ''user data''. Index data are system data distinct from user data, and consist primarily of [[Pointer (computing)|pointers]]. As user data are changing in a database (by insert, delete, or modify operations), also indexes go over changes to maintain user data access correct. '''Index locking''' is a technique utilized to maintain index integrity. A portion of an index is locked during a database transaction when this portion is being accesses by the transaction as a result of attempt to access related user data. Also special database system's transactions (not user invoked transactions) may be invoked to maintain and modify an index, as part of a system's self-maintenance activities. When a portion of index is locked by a transaction, other transactions may be blocked from accessing this index portion (blocked from modifying, and even from reading it, depending on lock type and needed operation).
In [[database]]s an ''[[Index (database)|index]]'' is a data structure, part of the database, utilized by a database system to effectively navigate access to ''user data''. Index data are system data distinct from user data, and consist primarily of [[Pointer (computing)|pointers]]. As user data are changing in a database (by insert, delete, or modify operations), also indexes go over changes to maintain user data access correct. '''Index locking''' is a technique utilized to maintain index integrity. A portion of an index is locked during a database transaction when this portion is being accesses by the transaction as a result of attempt to access related user data. Also special database system's transactions (not user invoked transactions) may be invoked to maintain and modify an index, as part of a system's self-maintenance activities. When a portion of index is locked by a transaction, other transactions may be blocked from accessing this index portion (blocked from modifying, and even from reading it, depending on lock type and needed operation).


Specialized [[concurrency control]] techniques exist for accessing indexes. These techniques depend on the index type, and take advantage of its structure. They are typically much more effective than applying to indexes common concurrency control methods applied to user data. Notable and have been widely researched are specialized techniques for [[B-tree]]s ([[B-Tree concurrency control]]) which are regularly utilized as database indexes.
Specialized [[concurrency control]] techniques exist for accessing indexes. These techniques depend on the index type, and take advantage of its structure. They are typically much more effective than applying to indexes common concurrency control methods applied to user data. Notable and have been widely researched are specialized techniques for [[B-tree]]s ([[B-Tree concurrency control]]<ref name=Graefe2010>Goetz Graefe (2010): [http://portal.acm.org/citation.cfm?id=1806908 "A survey of B-tree locking techniques"] ''ACM Transactions on Database Systems'' (TODS), Volume 35 Issue 3, July 2010 (also [http://www.hpl.hp.com/techreports/2010/HPL-2010-9.pdf HPL-2010-9], HP Laboratories).</ref>) which are regularly utilized as database indexes.


Index locks are typically shorter-lived than the common transaction locks on user data, and often called in the professional literature ''[[latch]]es''.
Index locks are used to coordinate [[Thread (computer science)|thread]]s accessing indexes concurrently, and typically shorter-lived than the common transaction locks on user data. Often they are called in the professional literature ''[[latch]]es''<ref name=Graefe2010/>.


===See also===
===See also===
Line 12: Line 12:
*[[Lock (database)]]
*[[Lock (database)]]
*[[B-Tree concurrency control]]
*[[B-Tree concurrency control]]

==References==

<references/>


{{DEFAULTSORT:Index Locking}}
{{DEFAULTSORT:Index Locking}}

Revision as of 00:21, 18 January 2011

In databases an index is a data structure, part of the database, utilized by a database system to effectively navigate access to user data. Index data are system data distinct from user data, and consist primarily of pointers. As user data are changing in a database (by insert, delete, or modify operations), also indexes go over changes to maintain user data access correct. Index locking is a technique utilized to maintain index integrity. A portion of an index is locked during a database transaction when this portion is being accesses by the transaction as a result of attempt to access related user data. Also special database system's transactions (not user invoked transactions) may be invoked to maintain and modify an index, as part of a system's self-maintenance activities. When a portion of index is locked by a transaction, other transactions may be blocked from accessing this index portion (blocked from modifying, and even from reading it, depending on lock type and needed operation).

Specialized concurrency control techniques exist for accessing indexes. These techniques depend on the index type, and take advantage of its structure. They are typically much more effective than applying to indexes common concurrency control methods applied to user data. Notable and have been widely researched are specialized techniques for B-trees (B-Tree concurrency control[1]) which are regularly utilized as database indexes.

Index locks are used to coordinate threads accessing indexes concurrently, and typically shorter-lived than the common transaction locks on user data. Often they are called in the professional literature latches[1].

See also

References

  1. ^ a b Goetz Graefe (2010): "A survey of B-tree locking techniques" ACM Transactions on Database Systems (TODS), Volume 35 Issue 3, July 2010 (also HPL-2010-9, HP Laboratories).