Loading...

XML

Word

Printable

JSON

Type: Improvement
Resolution: Gone away
Priority: Major - P3
Fix Version/s: None
Affects Version/s: None
Component/s: None
Labels:
- techdebt

Assigned Teams:

Storage Execution
Sprint:
Execution Team 2021-11-15, Execution Team 2022-01-24
Confidence Status:
None
Work Order:
3
CAR Domain/s:
None

Aha! Reference:
None
Tracking Level:
None
Risk Status:
None
Exec Notes:
None
Goal Name(s):
None
Goal Link:
None

mongos currently runs without a full featured resource lock manager. OperationContext instances are created with LockerNoop for the lock implementation, which has sometimes led to issues such as those described in ~~SERVER-59591~~.

This ticket looks into whether it makes sense to install a lock manager for mongos with a lock implementation closer to that in LockerImpl.

is depended on by

SERVER-26879 Get rid of LockerNoop

Closed

is related to

SERVER-59591 LockerNoop::isW() always returns true allowing multiple operations think they are holding the global exclusive lock at the same time

Closed

SERVER-42901 Use LockerImpl for the startup code path instead of LockerNoop

Closed

SERVER-59618 Avoid using LockerNoop outside of unit tests

Closed

SERVER-77353 Get rid of the Locker implementation for MongoS

Closed

related to

SERVER-77613 Complete TODO listed in SERVER-60229

Closed

(1 related to)

Assignee:: [DO NOT USE] Backlog - Storage Execution Team
Reporter:: Benety Goh
Participants:: [DO NOT USE] Backlog - Storage Execution Team, Benety Goh, Kaloian Manassiev
Votes:: 0 Vote for this issue
Watchers:: 4 Start watching this issue

Created:: Sep 26 2021 10:40:23 PM UTC
Updated:: Oct 27 2023 08:45:55 PM UTC
Resolved:: May 31 2023 07:14:43 AM UTC
Confidence Status Last Update:: 11/Nov/21 11:34 AM

Details

Description

Attachments

Issue Links

Forms

Activity

People

Dates