-
Type: Bug
-
Resolution: Fixed
-
Priority: Critical - P2
-
Affects Version/s: 4.0.0-rc0
-
Component/s: Concurrency, Replication
-
Fully Compatible
-
ALL
-
v4.0
-
Repl 2018-06-18
Attempting to acquire a LockManager lock while holding a mutex is prone to deadlock. The SessionCatalog::scanSessions() function locks the session catalog and executes an arbitrary function on any matching sessions. For the "killSessions" command, this means that while holding the SessionCatalog::_mutex, it calls CursorManager::killAllCursorsForTransaction(), which for a find cursor attempts to acquire the collection lock in CursorManager::withCursorManager(). Since the killAllExpiredTransactions() function also calls SessionCatalog::scanSessions(), it isn't possible to reap expired transactions while the "killSessions" command is running. It similarly isn't possible to commit or abort a transaction while the "killSessions" command is running because SessionCatalog::checkOutSession() must acquire the SessionCatalog::_mutex.
- is related to
-
SERVER-34781 Abandoned cursor in a transaction can block other operations
- Closed
-
SERVER-34732 collection drop hangs in test of transactions
- Closed
-
SERVER-34795 killSessions should kill transactions prior to killing cursors
- Closed
-
SERVER-34779 Check the dbhash periodically in a new version of the replica_sets_jscore_passthrough.yml test suite
- Closed
- related to
-
SERVER-35770 Running a multi-statement transaction when all WiredTiger write tickets are exhausted may lead to deadlock
- Closed
-
SERVER-42550 Complete TODO listed in SERVER-35217
- Closed