[SERVER-36736] Avoid doing work in Client lock when destroying OperationContextSession Created: 17/Aug/18  Updated: 29/Oct/23  Resolved: 28/Aug/18

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

Type: Bug Priority: Major - P3
Reporter: Matthew Russotto Assignee: Matthew Russotto
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
is related to SERVER-36007 Attempting to check out an already ch... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2018-08-27, Repl 2018-09-10
Participants:
Linked BF Score: 11

 Description   

When OperationContextSession is destroyed, it destroys the operationSessionDecoration on the OperationContext under the Client lock.  Destroying the operationContextDecoration (which is a ScopedCheckedOutSession) takes the SessionCatalog mutex.  Other code takes the SessionCatalog mutex and then the Client lock (implicitly in waitForConditionOrInterruptUntil) so this causes deadlocks.

Instead we should take the Client lock, move the ScopedCheckedOutSession from the operationSessionDecoration to a local variable, then release the Client lock and destroy the ScopedCheckedOutSession without the lock.



 Comments   
Comment by Githook User [ 28/Aug/18 ]

Author:

{'name': 'Matthew Russotto', 'email': 'matthew.russotto@10gen.com', 'username': 'mtrussotto'}

Message: SERVER-36736 Avoid doing work in Client lock when destroying OperationContextSession.
Branch: master
https://github.com/mongodb/mongo/commit/9b45c3bb604a5ac661383a75ab1a94d9f8b1d8df

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