-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
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
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.
- 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 related to
-
SERVER-34951 LockerImpl should invariant against active UninterruptibleLockGuard usage when _maxLockTimeout is set
- Blocked
-
SERVER-34924 Treat LockTimeout as transient transaction error
- Closed
-
SERVER-35023 Add server parameter maxTransactionLockRequestTimeoutMillis test
- Closed