[SERVER-50018] lock order is reversed when updating config.transactions Created: 30/Jul/20  Updated: 06/Dec/22  Resolved: 06/Aug/20

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

Type: Bug Priority: Major - P3
Reporter: Randolph Tan 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:
Depends
Related
is related to SERVER-36883 support non-doc-locking storage engin... Closed
Assigned Teams:
Sharding
Operating System: ALL
Participants:
Case:

 Description   

Operations that work on the config database would take the config db lock first and then the local db lock to write to the oplog. However, when updating config.transactions for retryable writes or transactions, the local lock is taken first and then followed by config. At first glance it may look like the logOp is taking the local lock in this scope, but there are certain cases where unlock can be deferred until WUOW is finished. And the oplog write during retryable write or transactions falls into this case. In summary, what appeared to be a sequence of [lock local, unlock local, lock config, unlock config] is in fact, [lock local, (defer unlock local), lock config, unlock config, (unlock local for real)].



 Comments   
Comment by Randolph Tan [ 30/Jul/20 ]

Mongo >  v4.0.3 is not affected by this when using storage engine with doc level locking like WT.

Comment by James Kovacs [ 30/Jul/20 ]

Since logOp no longer takes a lock on local in 4.0, is MongoDB 4.0+ affected by this deadlock?

Generated at Thu Feb 08 05:21:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.