[SERVER-23844] Distributed lock manager should not schedule unlock if the lock acquisition did not result in a write Created: 21/Apr/16  Updated: 06/Dec/22  Resolved: 12/Dec/19

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

Type: Bug Priority: Minor - P4
Reporter: Kaloian Manassiev Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-22971 Operations on some sharded collection... Closed
Assigned Teams:
Sharding
Operating System: ALL
Participants:

 Description   

If lock acquisition fails for anything other than LockStateChangeFailed, the sharding distributed lock manager will schedule an unlock in order to cleanup any potentially bad leftover state.

In case of errors, where we know that the lock attempt definitely did not modify any documents, we should not schedule this unlock attempt in order to reduce the amount of logging and mitigate log overflow such as the one described in SERVER-22971.


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