[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: |
|
||||
| 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: initializeOperationSessionInfo is called without the client lock, which This can cause data races with readers operating under the lock, causing This takes the lock around writes, which should solve the races. |
| 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? |