-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
Fully Compatible
-
Repl 2018-03-26, Repl 2018-04-09
-
45
This ticket covers the following implicit abort cases.
- When a transaction is open and the server receives an operation with a higher transactionId on the same session, the existing transaction will be aborted and a new transaction will be started.
- Any time the storage engine tells us to.
- If a transaction encounters a WriteConflictException at any point.
- When the transaction tries to access its storage engine layer transaction and discovers that the storage transaction has been aborted. This would happen whenever the storage engine decides to kill an ongoing transaction for any reason (for example due to WT cache pressure).
It doesn't cover the following cases.
- When they see an operation on the same transaction with a ‘stmtId’ that has already been seen on that transaction.
- When the primary driving the transaction steps down.
- When the session expires.
- When the transaction has been alive for more than 1 minute.
- If a transaction fails to acquire a database lock at any point.
- When a transaction tries to commit but discovers that the applyOps commit entry it would generate is too large (greater than 16 MB).
- is duplicated by
-
SERVER-33671 Bumping txnNumber does not clear stashed transaction resources
- Closed
- is related to
-
SERVER-34059 DuplicateKeyError aborts transaction
- Closed
-
SERVER-33315 Fail creating a new txn if there is a current transaction still running on the session.
- Closed
-
SERVER-34055 Convert WriteConflictException error to TransactionAborted
- Closed
- related to
-
SERVER-34011 Concurrency between transaction and other threads that can abort transaction
- Closed
-
SERVER-42552 Complete TODO listed in SERVER-33432
- Closed