[SERVER-36201] Refactor coupled transactions metrics tracking code into methods Created: 19/Jul/18  Updated: 29/Oct/23  Resolved: 17/Aug/18

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

Type: Task Priority: Major - P3
Reporter: Jinny Byun Assignee: Jinny Byun
Resolution: Fixed Votes: 0
Labels: global-txn-metrics, per-txn-metrics
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Repl 2018-08-13, Repl 2018-08-27
Participants:

 Description   

Currently, there are some transactions metrics that are always updated together. We would like to group these metrics together and create methods that will allow us to update coupled metrics at the same time.

SingleTransactionStats::LastClientInfo::update and SingleTransactionStats::OpDebug::AdditiveMetrics::add are called together in

SingleTransactionStats::setEndTime and SingleTransactionStats::setInactive are called together in

ServerTransactionMetrics::decrementCurrentOpen and ServerTransactionMetrics::incrementTotalAborted are called together in



 Comments   
Comment by Githook User [ 17/Aug/18 ]

Author:

{'name': 'jinichu', 'email': 'jinnybyun@gmail.com', 'username': 'jinichu'}

Message: SERVER-36201 Refactor transactions metrics tracking code into TransactionMetricsObserver
Branch: master
https://github.com/mongodb/mongo/commit/59d4d78a68ef6347120c6dfcd6da6ec3d325722f

Comment by William Schultz (Inactive) [ 02/Aug/18 ]

Note: As part of this refactor we might also want to make sure that we are using the same value of "now" when we update various stats in SingleTransactionStats collectively e.g. https://github.com/mongodb/mongo/blob/70550cf9e211611c396020f0027bd64a6e5b99c0/src/mongo/db/session.cpp#L949-L953

Comment by William Schultz (Inactive) [ 31/Jul/18 ]

jinny.byun A thought on the implementation strategy for this. We could consider creating a TransactionMetricsObserver class, with methods like onStash, onUnstash, onCommit, onAbort, etc., that get called when the appropriate transaction event occurs. We could consider defining this class in a separate file, but making it a friend class of Session (or eventually TransactionParticipant). That way it would still have access to the private members of Session. For each observer method, we could simply pass in the necessary state needed to update the relevant metrics as function arguments. If we refactor the existing metrics tracking logic in accordance with this, it may allow us to condense most of the metrics update logic inside Session to a few method calls throughout the file. Most of the substantial metric tracking logic would exist inside the TransactionsMetricsObserver handler functions. This could potentially make backporting all of the transactions metrics changes to 4.0 much easier, if the only changes to Session are a few scattered method calls. TransactionsMetricsObserver would be a new file that encapsulates most of the metrics tracking logic, so backporting it would not be an issue.

Comment by William Schultz (Inactive) [ 31/Jul/18 ]

We will not necessarily aim to backport this to 4.0.

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