[SERVER-67850] AutoGetCollection doesn't always take db lock Created: 07/Jul/22  Updated: 27/Oct/23  Resolved: 07/Jul/22

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

Type: Bug Priority: Major - P3
Reporter: Louis Williams Assignee: Kaloian Manassiev
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
is caused by SERVER-66869 Get rid of the multi DB locking capab... Closed
Operating System: ALL
Sprint: Sharding EMEA 2022-07-11
Participants:

 Description   

AutoGetCollection (AGC) accepts a NamespaceStringOrUUID which can either store a full namespace string or a database name and UUID.

This call to NamespaceStringOrUUID::db() does not consider the case where AGC is constructed with a full namespace string. As a result, it takes a database lock on an empty namespace.



 Comments   
Comment by Janna Golden [ 07/Jul/22 ]

There's a ticket to remove dbname() (SERVER-66887) already, but we'll probably leave both dbName() and db() - these existed prior to changing namespaces to include the tenantId. One is a getter for the "_dbName" member on the NSSOrUUID object. The other returns either the "_dbName" member or the db name on the "_nss" member - I think it was added a few years ago so callers wouldn't have to manually check which member was initialized.

Comment by Kaloian Manassiev [ 07/Jul/22 ]

We should probably get rid of these functions. I think they are vestiges of the transformation to move to Tenant-including namespaces.

CC janna.golden@mongodb.com

Comment by Louis Williams [ 07/Jul/22 ]

I apologize, the db() function does the correct thing and handles both the namespace string and dbname + UUID case. The dbname() and dbName() functions do not do the correct thing.

Sorry to raise any alarms!

Comment by Louis Williams [ 07/Jul/22 ]

CC kaloian.manassiev@mongodb.com, I believe this change was introduced by SERVER-66869 unintentionally.

Generated at Thu Feb 08 06:09:13 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.