[DOCS-16009] [Server] Correct description of listCollections locking behavior Created: 04/Apr/23 Updated: 13/Nov/23 Resolved: 05/Aug/23 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual, Server |
| Affects Version/s: | None |
| Fix Version/s: | 4.4, 5.0.0, 6.0.0, 6.3, 7.0.0, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Adam Harrison | Assignee: | Jason Price |
| Resolution: | Done | Votes: | 0 |
| Labels: | quick-win, server-docs-bug-bash | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: | |
| Days since reply: | 26 weeks, 6 days ago |
| Story Points: | 3 |
| Description |
|
The Locks section of the documentation for the listCollections command is outdated. For all versions, the description currently states: The listCollections command takes Intent Shared lock on the database. In previous versions, the command takes Shared lock on the database. Unless the nameOnly option is specified, the command also takes an Intent Shared lock on each of the collections in turn while holding the Intent Shared lock on the database. This seems to only have been accurate for MongoDB 4.0. Per this comment - in MongoDB 4.2 and 4.4 listCollections will take an Intent Shared lock on each collection while holding the Intent Shared lock on the database. In MongoDB 5.0 and later, listCollections does not take an intent shared lock on either the Collection or Database level (SERVER-53829) |
| Comments |
| Comment by Jason Price [ 03/Aug/23 ] |