Details
-
Bug
-
Resolution: Fixed
-
Major - P3
-
None
-
None
-
None
-
Fully Compatible
-
ALL
-
Execution Team 2022-07-11, Execution Team 2022-07-25
Description
Since our lock manager works based on namespaces and not UUIDs, there is an "optimistic" protocol which ensures that a UUID is locked exactly as the namespace that it maps to. The protocol is:
do {
|
NSSBeforeLock = optimistically resolve NSS to UUID;
|
Lock the NSS();
|
NSSAfterLock = optimistically resolve NSS to UUID;
|
while (NSSBeforeLock == NSSAfterLock);
|
The above protocol guarantees that when one holds an AutoGetCollection object, the NSS <-> UUID mapping reflects the truth and is stable for the duration of the RAII object.
The multi-collection locking path performs the UUID -> NSS resolution before it invokes the CollectionLock constructor (which is what implements the protocol above) and as a result it is possible that the guarantee above is not met. This is easily reproducible if the "fast" path here is skipped.
Attachments
Issue Links
- is related to
-
SERVER-67383 Layering violation in the lock manager
-
- Closed
-