[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: |
| 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. |