[SERVER-40202] TransactionCoordinator doesn't update replica set monitors based on participant responses Created: 18/Mar/19  Updated: 29/Oct/23  Resolved: 10/Apr/19

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

Type: Bug Priority: Major - P3
Reporter: Jack Mulrow Assignee: Jack Mulrow
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-39991 Add transactions workloads to failove... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2019-03-25, Sharding 2019-04-08, Sharding 2019-04-22
Participants:

 Description   

To drive a two phase commit, TransactionCoordinators target shards using the replica set monitors in the ShardRegistry. The TransactionCoordinator does not update these replica set monitors with the response from the targeted host, so if the error is retryable and indicates the targeted host is no longer a primary, e.g. a stepdown error, the TransactionCoordinator will re-target the same node until the corresponding replica set monitor refreshes for some other reason. Instead, the TransactionCoordinator should update the appropriate RSM for each response it receives, like in ShardRemote::_runCommand.



 Comments   
Comment by Luke Chen [ 11/Apr/19 ]

Fixing up the fixVersion as this ticket was not included as part of 4.1.10 release.

Comment by Githook User [ 10/Apr/19 ]

Author:

{'email': 'jack.mulrow@mongodb.com', 'name': 'Jack Mulrow', 'username': 'jsmulrow'}

Message: SERVER-40202 TransactionCoordinator should update replica set monitors based on participant responses
Branch: master
https://github.com/mongodb/mongo/commit/6ad0264d3e2633439b3adeda97f5eb52240b1fc0

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