Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Multiple granularity locking
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Lock modes== In addition to shared ('''S''') locks and exclusive ('''X''') locks from other locking schemes, like strict two-phase locking, MGL also uses intentional "locks", which do not directly lock a node, but instead denote the existence, or intent to add, a lock of the specified type lower in the node hierarchy. Intentional locks include "intention shared" ('''IS'''), "intention exclusive" ('''IX'''), and the combined "shared and intention exclusive" ('''SIX''') locks. '''IS''' locks conflict with '''X''' locks, while '''IX''' locks conflict with '''S''' and '''X''' locks. The null lock ('''NL''') is compatible with everything. To lock a node in '''S''' (or '''X'''), MGL has the transaction lock on all of its ancestors with '''IS''' (or '''IX'''), so if a transaction locks a node in '''S''' (or '''X'''), no other transaction can access its ancestors in '''X''' (or '''S''' and '''X'''). This protocol is shown in the following table: {| class="wikitable" | '''To Get''' || '''Must have on all ancestors''' |- | IS or S || IS or IX |- | IX, SIX or X || IX or SIX |} Determining what level of granularity to use for locking is done by locking the finest level possible (i.e., at the lowest leaf), and then escalating these locks to higher levels in the file hierarchy to cover more records or file elements as needed in a process known as "lock escalation". MGL locking modes are compatible with each other as defined in the following matrix. {| class="wikitable" |- ! Mode || NL || IS || IX || S || SIX || X |- ! NL | {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} |- ! IS | {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{No}} |- ! IX | {{Yes}} || {{Yes}} || {{Yes}} || {{No}} || {{No}} || {{No}} |- ! S | {{Yes}} || {{Yes}} || {{No}} || {{Yes}} || {{No}} || {{No}} |- ! SIX | {{Yes}} || {{Yes}} || {{No}} || {{No}} || {{No}} || {{No}} |- ! X | {{Yes}} || {{No}} || {{No}} || {{No}} || {{No}} || {{No}} |} Following the locking protocol and the compatibility matrix, if one [[Database transaction|transaction]] holds a node in S mode, no other transactions can have locked any ancestor in X mode.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)