Details
-
Bug
-
Status: Closed
-
Major - P3
-
Resolution: Fixed
-
None
-
None
-
Fully Compatible
-
ALL
-
Storage NYC 2018-03-26, Storage NYC 2018-04-09, Storage NYC 2018-03-12, Storage NYC 2018-04-23, Storage NYC 2018-05-07, Storage NYC 2018-05-21
-
58
Description
Txns should do no waiting for locks, they should fail the lock acquisition immediately if there's any conflict. They should also abort the transaction if that happens.
Attachments
Issue Links
- depends on
-
SERVER-34829 Drop pending reaper must not delete the _dropPendingNamespaces entry until after the drop occurs
-
- Closed
-
-
SERVER-34372 Drop collection command with majority write concern should wait until two-phase drop finishes
-
- Closed
-
- is depended on by
-
SERVER-34726 Deadlock with locally stashed transaction resources during profiling
-
- Closed
-
-
SERVER-34800 The transaction aborter thread should acquire locks with a 0-second lock acquisition timeout
-
- Closed
-
- is documented by
-
DOCS-11716 Docs for SERVER-33244: Make all lock acquisitions for transactions have 0 second timeout
-
- Closed
-
- is related to
-
SERVER-34951 LockerImpl should invariant against active UninterruptibleLockGuard usage when _maxLockTimeout is set
-
- Backlog
-
-
SERVER-34924 Treat LockTimeout as transient transaction error
-
- Closed
-
-
SERVER-35023 Add server parameter maxTransactionLockRequestTimeoutMillis test
-
- Closed
-