[SERVER-38134] Ensure config.transactions and TransactionParticipant have consistent state after every command Created: 14/Nov/18  Updated: 27/Oct/23  Resolved: 12/Feb/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: Randolph Tan
Resolution: Works as Designed Votes: 0
Labels: prepare_errors
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-38133 When asked to continue a transaction ... Closed
is related to SERVER-40051 Make committingWithoutPrepare state u... Closed
is related to SERVER-38135 Do not allow transactions on shard se... Closed
Sprint: Sharding 2019-01-28, Sharding 2019-02-11, Sharding 2019-02-25
Participants:

 Description   

We require that config.transactions and TransactionParticipant have consistent state after every command (or the session is invalidated) so that subsequent users of TransactionParticipant know whether the session needs to be reloaded from disk. We will always update config.transactions before updating the in-memory state in TransactionParticipant. If we throw an exception before updating the in-memory state, we must invalidate the session. Audit all abort, commit, and prepare codepaths to ensure they follow this pattern



 Comments   
Comment by Randolph Tan [ 12/Feb/19 ]

prepare:
If something throws an exception before prepare completes, the abort guard will get triggered and abort the transaction.

commit prepared:
After the sanity checks, the entire block is wrapped in a try catch block that terminates if it catches any exception.

Comment by Randolph Tan [ 31/Jan/19 ]

Commit unprepared:
SImilar to abort, update happens while mutex is released but session is checked out. Also no non-fatal early returns before setting the _state variable (other than txnNumber being no longer active).

Comment by Randolph Tan [ 30/Jan/19 ]

As of 02a532609f5e4b5c7cde64a4f0444cb5dc0dcb3e.

abort command:
Update to config.transactions occur at opObserver onTransactionAbort, while TransactionParticipant mutex is released. The TxnParticipant in memory lastWriteTS gets updated during the RecoveryUnit (of the config.transaction update) onCommit callback, also while TxnParticipant mutex is released. However, session is still checked out, so no other thread (like migration, TxnRepaer) can modify the TxnParticipant. It then grabs the mutex again and tries to set the TxnParticipant state to abort. In between the config.txn update and TxnParticipant update, there are no non-fatal early returns that would leave the TxnParticipant usable but out-of-sync.

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