-
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
-