[SERVER-33432] Implicit transaction abort Created: 21/Feb/18  Updated: 29/Oct/23  Resolved: 04/Apr/18

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 3.7.4

Type: Task Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Siyuan Zhou
Resolution: Fixed Votes: 0
Labels: todo_in_code
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
is duplicated by SERVER-33671 Bumping txnNumber does not clear stas... Closed
Related
related to SERVER-34011 Concurrency between transaction and o... Closed
related to SERVER-42552 Complete TODO listed in SERVER-33432 Closed
is related to SERVER-34059 DuplicateKeyError aborts transaction Closed
is related to SERVER-33315 Fail creating a new txn if there is a... Closed
is related to SERVER-34055 Convert WriteConflictException error ... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2018-03-26, Repl 2018-04-09
Participants:
Linked BF Score: 45

 Description   

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


 Comments   
Comment by Siyuan Zhou [ 04/Apr/18 ]

Moving the patch that disallows reusing aborted transaction number to SERVER-33501 and closing this ticket.

Comment by Githook User [ 28/Mar/18 ]

Author:

{'email': 'siyuan.zhou@mongodb.com', 'name': 'Siyuan Zhou', 'username': 'visualzhou'}

Message: SERVER-33432 Move transaction abort test into jsCore_txns test suite.
Branch: master
https://github.com/mongodb/mongo/commit/088399a31d76dcc97aa84e66d1fdc774b98f4358

Comment by Githook User [ 27/Mar/18 ]

Author:

{'email': 'siyuan.zhou@mongodb.com', 'name': 'Siyuan Zhou', 'username': 'visualzhou'}

Message: SERVER-33432 Abort transaction on write conflicts and other exceptions.
Branch: master
https://github.com/mongodb/mongo/commit/8060a008b5dce908553cec373bd6667c30b97fe0

Comment by Githook User [ 27/Mar/18 ]

Author:

{'email': 'siyuan.zhou@mongodb.com', 'name': 'Siyuan Zhou', 'username': 'visualzhou'}

Message: SERVER-33432 Abort existing transaction when a new transaction is started on the same session.
Branch: master
https://github.com/mongodb/mongo/commit/3cf7ebe0c5f0975cc38cebb10fd1b47367f713c0

Comment by Dianna Hohensee (Inactive) [ 27/Mar/18 ]

Linking SERVER-33295 as depending on this. I need an insert op using an aborted transaction's txnNumber to fail for my testing, to make sure the transaction was aborted as expected.

Comment by Tess Avitabile (Inactive) [ 20/Mar/18 ]

This ticket should also cover the case where the _activeTxnNumber is bumped due to chunk migration.

Comment by Tess Avitabile (Inactive) [ 16/Mar/18 ]

Great, I will close SERVER-33671 as a duplicate.

Comment by Siyuan Zhou [ 15/Mar/18 ]

tess.avitabile, yes. I believe they are the same issue. Thanks for the repo, which will be very useful for my testing.

Comment by Tess Avitabile (Inactive) [ 15/Mar/18 ]

siyuan.zhou, do you expect to fix SERVER-33671 as part of this work? Initially we considered this a bug in the stash mechanism implemented for snapshot reads, but maybe it is part of the framework for auto-aborting transactions when the active transaction number is bumped.

Comment by Siyuan Zhou [ 13/Mar/18 ]

This ticket should also ensure that the txnNumber for the aborted transaction cannot be reused for another transaction.

Comment by Tess Avitabile (Inactive) [ 08/Mar/18 ]

This ticket should also cover local snapshot reads and include testing.

Generated at Thu Feb 08 04:33:23 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.