[SERVER-38108] ServerTransactionsMetrics should synchronize access to non-atomic members Created: 13/Nov/18  Updated: 29/Oct/23  Resolved: 29/Nov/18

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.1.6

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

Issue Links:
Depends
Problem/Incident
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2018-12-03
Participants:
Linked BF Score: 73

 Description   

The ServerTransactionsMetrics class is a service context decoration that maintains server-wide stats for transactions, including the opTimes of uncommitted/aborted transactions. The sets of opTimes are modified by TransactionParticipant through the TransactionMetricsObserver in several places (e.g. onPrepare) and by the ReplicationCoordinator when getting the stable timestamp. There is no internal synchronization for the lists of opTimes, so they can be concurrently modified, leading to data races.

A simple fix would be to add a mutex to ServerTransactionsMetrics that protects these variables. The other member variables in the class are atomics, so they are already thread-safe.



 Comments   
Comment by Githook User [ 29/Nov/18 ]

Author:

{'name': 'Pavi Vetriselvan', 'email': 'pvselvan@umich.edu', 'username': 'pvselvan'}

Message: SERVER-38108 ServerTransactionMetrics should synchronize
Branch: master
https://github.com/mongodb/mongo/commit/aabd9f0d30d089edc48befce977356d543880aba

Comment by Judah Schvimer [ 13/Nov/18 ]

CC pavithra.vetriselvan

Comment by Tess Avitabile (Inactive) [ 13/Nov/18 ]

The mutex acquisition under the replication coordinator mutex will go away when we stop pinning the stable timestamp, so I am not too worried about that one.

Comment by Andy Schwerin [ 13/Nov/18 ]

I'm nervous about adding mutex acquisitions underneath the replication coordinator mutex, because that mutex is the hottest in the system.

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