[SERVER-56155] Locks for capped collection's metadata in CollectionImpl don't seem to do what they claim Created: 19/Apr/21  Updated: 27/Oct/23  Resolved: 22/Apr/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Denis Protivensky Assignee: Dmitry Agranat
Resolution: Community Answered Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Participants:

 Description   

There are two identical pieces of code in CollectionImpl::_insertDocuments() and CollectionImpl::updateDocument() that grab metadata X-lock for capped collections:

 

if (_shared->_needCappedLock) {
 // X-lock the metadata resource for this capped collection until the end of the WUOW. This
 // prevents the primary from executing with more concurrency than secondaries.
 // See SERVER-21646.
 Lock::ResourceLock heldUntilEndOfWUOW{
 opCtx->lockState(), ResourceId(RESOURCE_METADATA, _ns.ns()), MODE_X};
}

The lock won't be held until the end of WUOW as it will be released after leaving the scope.

Is the comment wrong or is the code wrong?



 Comments   
Comment by Dmitry Agranat [ 22/Apr/21 ]

Glad to hear you have figured this out fordeso2@gmail.com. I thought you might also be interested to follow SERVER-55476 which should improve database-level exclusive locking granularity for both reads and writes when the profiler is enabled.

Comment by Denis Protivensky [ 19/Apr/21 ]

Okay, I didn't check that unlocking of RESOURCE_METADATA will be delayed for MODE_X as for most other resource types. Shouldn't be the issue then.

Generated at Thu Feb 08 05:38:30 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.