[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: |
|
||||||||
| 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 |