Intent locks are higher level locks acquired before lower level locks are put in place and are called this way as they signal the intent of these lower level locks. Regarding the different types, intent shared locks are put in place for read operations that do not change or update data, such as a find()
query whereas intend exclusive locks are put in place for data-modification operations, such as save()
, update
and remove
.
To illustrate this, take this example collection:
db.data.save({"name":"John"})
db.data.save({"name":"Jane"})
if you run the find query below, an intent shared lock is requested on the Jane
record. As this query does not update the data, other users can run the same query or with other words, there can be multiple intent shared locks on the same record.
db.data.find({"name":"Jane"})
However, if you now run this query:
db.data.update({name:"Jane"},{name:"Janet"})
and intent exclusive lock is requested as this operation changes the record. This lock can't be put in place until all other locks have been released on this record (or collection). While the exclusive lock is in place, no other intent locks can be applied on the record (or collection). This means, that if the update
operation would take a considerable amount of time, any find
operation would be blocked during the duration of the exclusive lock is in place.
Please note that the locking behaviour has significantly improved since version 2.4. In version 2.4 intent exclusive locks where applied at the database level, whereas for version 3.0 locks are only at collection level when using the MMAPv1 storage engine and at record level when using the WiredTiger storage engine (default in 3.2).
Regarding the difference between the intent locks IS and IX and the lower level locks S and X, the intent locks are high level locks that act as a traffic signal. Once the intent locks are in place (e.g. at collection level), the lower level locks are put in place (e.g. at document level). This design reduces the processing needed for managing locks as a concurrent sessions only has to read the intent locks and not all the lower level locks.