[SERVER-36799] Move transaction related functionality from Session into TransactionParticipant Created: 21/Aug/18  Updated: 08/Jan/24  Resolved: 08/Oct/18

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

Type: Bug Priority: Major - P3
Reporter: Siyuan Zhou Assignee: Kaloian Manassiev
Resolution: Fixed Votes: 0
Labels: ShardedTxn:SessionRefactor
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-36848 Bumping txnNumber on Session must alw... Closed
is depended on by SERVER-37244 Implement checkOutSessionForKill API ... Closed
is depended on by SERVER-37245 Use the SessionCatalog to track sessi... Closed
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2018-09-24, Sharding 2018-10-08, Sharding 2018-10-22
Participants:

 Description   

SERVER-35900 made TransactionParticipant as a decoration of Session, but this causes a lot of cross-component references between Session and TransactionParticipant. Instead, we should move everything that's related to Transactions out of Session and into TransactionParticipant.



 Comments   
Comment by Githook User [ 08/Oct/18 ]

Author:

{'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}

Message: SERVER-36799 Move all transactions and retryable writes functionality from Session into TransactionParticipant

This change leaves the Session class to be a plain decorable structure
only used for serialization of operations on the same logical session.
Branch: master
https://github.com/mongodb/mongo/commit/b272bf351c39677d1e87d5c7fcd8b15b61465012

Comment by Githook User [ 12/Sep/18 ]

Author:

{'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}

Message: SERVER-36799 Get rid of the separate TransactionParticipant 2PC state machine
Branch: master
https://github.com/mongodb/mongo/commit/d6336b278148540584eb39a658057dc8ae442788

Comment by Andy Schwerin [ 24/Aug/18 ]

Just don't name it TransactionManager. I'm already trying to prevent the sharding team from naming a class TransactionCoordinatorManager.

Comment by Siyuan Zhou [ 24/Aug/18 ]

As we decided to make Session thin, we can add another indirected layer TransactionManager, which is a decoration on Session and owns TransactionParticipant. TxnNumber is then a member of TransactionManager.

There is a one-to-one mapping between the txnNumber to one of the transaction roles: retryable write (no transaction), participant and coordinator. At a given time, the transaction on a session can only be one of the three. A coordinator may owns another participant, but it's different from the one owned by TransactionManager. Bumping txnNumber on TransactionManager will try to abort the current role, which throws an exception if it can't. The benifits are
1) to capture the exclusiveness of the transaction roles;
2) to unify bumping txnNumber for all transaction roles, Kal's work on SERVER-36544 simplified this issue, but bumping the txnNumber is not protected by session checkout, when a prepared TransactionParticipant is stashed or when the coordinator is waiting for acks for a commit decision.
3) the instance lifetime of transaction roles is the same as it's logical lifetime.

Comment by Esha Maharishi (Inactive) [ 23/Aug/18 ]

Also, if we want to put Session on mongos, Session cannot know about TransactionParticipant.

Comment by Andy Schwerin [ 22/Aug/18 ]

There may be another solution by introducing constructor/destructor actions to sessions. I'd really like to avoid direct ownership of TP by Session.

Comment by Siyuan Zhou [ 21/Aug/18 ]

renctan, this ticket is from our conversation with mira.carey@mongodb.com, I filed it to make sure we don't forget the problem.

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