[SERVER-30782] initializeOperationSessionInfo should take the client lock while writing lsid Created: 22/Aug/17  Updated: 30/Oct/23  Resolved: 23/Aug/17

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: 3.5.13

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

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Platforms 2017-09-11
Participants:
Linked BF Score: 0

 Description   

initializeOperationSessionInfo is called without the client lock, which can cause it to do dirty partial writes to sessionId and txnNumber.

This can cause data races with readers operating under the lock, causing them to see partial writes



 Comments   
Comment by Ramon Fernandez Marina [ 24/Aug/17 ]

Author:

{'username': u'hanumantmk', 'name': u'Jason Carey', 'email': u'jcarey@argv.me'}

Message:SERVER-30782 setting lsid must take the clientlock

initializeOperationSessionInfo is called without the client lock, which
can cause it to do dirty partial writes to sessionId and txnNumber.

This can cause data races with readers operating under the lock, causing
them to see partial writes.

This takes the lock around writes, which should solve the races.
Branch:master
https://github.com/mongodb/mongo/commit/b2b2827fcf61c8da62b621778b50a0ac414951b1

Comment by Mira Carey [ 23/Aug/17 ]

Yeah, to the sessionId and txnNumber fields of the operation context in-memory object.

Comment by Andy Schwerin [ 22/Aug/17 ]

To clarify, by writes you mean writes to in-memory structures, not database files?

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