[SERVER-67540] Introduce listCommandsLocks command Created: 27/Jun/22  Updated: 06/Dec/22  Resolved: 08/Jul/22

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

Type: New Feature Priority: Major - P3
Reporter: Dmitry Agranat Assignee: Backlog - Storage Execution Team
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Storage Execution
Sprint: Execution Team 2022-07-25
Participants:

 Comments   
Comment by Geert Bosch [ 05/Jul/22 ]

Hi, it is quite hard to do this, as the exact locks taken often determines on the circumstances. For example, createIndexes may not take any locks if it finds that the requested index already exists, or it may just take a MODE_IX lock if it's run in a transaction on a collection created in that same transaction, or it might momentarily take a MODE_X lock and then MODE_IX during the bulk of the indexing. Then again it differs for the sharding case. In particular, for sharding there are often extra synchronization dependencies such as interactions with chunk migrations. So, there's a lot of relatively complex information that's also subject to constant change. I think that the MongoDB docs are the right place for this information, as it's not something that we can automatically derive from our code, or even check for consistency with out code.

Over time, we're working more and more toward everything being versioned, such that reads will never block and writes may just fail and/or retry due to conflicting concurrent operations.

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