[SERVER-71936] Time-series view and bucket collection are locked in different order in validation than other places Created: 07/Dec/22  Updated: 27/Oct/23  Resolved: 12/Jan/23

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

Type: Bug Priority: Major - P3
Reporter: Yuhong Zhang Assignee: Dianna Hohensee (Inactive)
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Storage Execution
Operating System: ALL
Sprint: Execution Team 2023-01-23
Participants:

 Description   

The validate command takes the lock on the view first while create and drop take the lock on the bucket collection first. This can lead to potential deadlock.



 Comments   
Comment by Dianna Hohensee (Inactive) [ 12/Jan/23 ]

Closing with Works as Designed.

Comment by Dianna Hohensee (Inactive) [ 10/Jan/23 ]

Investigation notes:

createCollection will first create the bucket collection under locks that go out of scope before next creating the view under appropriate locks. So there is no bucket/view namespace lock overlap.

dropCollection will drop the view entry under locks as part of a lambda internal to another function dropping the buckets collection already under locks before calling into the lambda. Therefore, drop first acquires a bucket namespace lock and then the view namespace lock. Note that the drop command enters with the time-series view namespace given to the drop function, not the buckets namespace – affects the code path chosen.

The validate cmd will push the user specified namespace into the validate locking logic unaltered. Locks are immediately taken on the given namespace whether or not a collection/view exists. If the namespace is not a collection, is a view and is time-series, then locks are taken on the buckets collection.

Ah. There is a trick here. The same variable _collectionLock holds the user specified time-series namespace lock AND the time-series buckets collection lock: taking a lock on the buckets release the time-series view namespace locks first. We only hold one collection-level lock at a time during validation.

yuhong.zhang@mongodb.com I think the deadlock might not be possible re the previous paragraph – I think the code could use some additional comments, though, if my analysis is correct, and you original thought validate held two collection locks across this code.

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