[SERVER-38133] When asked to continue a transaction whose txnNumber is too new, TransactionParticipant must abort that transaction Created: 14/Nov/18  Updated: 04/Jan/19  Resolved: 04/Jan/19

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

Type: Task Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Tess Avitabile (Inactive)
Resolution: Won't Fix Votes: 0
Labels: prepare_durability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-38132 Aborting a transaction must always up... Closed
related to SERVER-38850 Perform noop write before returning N... Closed
is related to SERVER-38134 Ensure config.transactions and Transa... Closed
is related to SERVER-38135 Do not allow transactions on shard se... Closed
Sprint: Repl 2018-12-03, Repl 2018-12-17, Repl 2019-01-14
Participants:

 Description   

When TransactionParticipant::_continueMutliDocumentTransaction() is called with a txnNumber that is higher than _activeTxnNumber, it returns NoSuchTransation but does not update _activeTxnNumber or abort the transaction. It must set _activeTxnNumber to txnNumber and abort the transaction (with the new txnNumber). This ensures that no future command may start a transaction with this txnNumber, so the commit decision for this txnNumber cannot change.



 Comments   
Comment by Tess Avitabile (Inactive) [ 04/Jan/19 ]

Closing in favor of SERVER-38850SERVER-38850 fixes all known problematic cases in 4.2. It is simpler, since it does not have upgrade/downgrade concerns, it does not require changes to rollback-via-refetch, it does not have concerns for secondary read-only transactions, and it does not have the question of how internal maintenance operations should handle the need to perform writes.

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