[SERVER-38466] Repeated reads concurrency workloads should reset prevDocuments when entire transaction is retried Created: 07/Dec/18  Updated: 29/Oct/23  Resolved: 10/Dec/18

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 4.1.7

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

Issue Links:
Depends
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2018-12-17
Participants:
Linked BF Score: 28

 Description   

The concurrency workloads multi_statement_transaction_atomicity_isolation_repeated_reads.js and multi_statement_transaction_simple_repeated_reads.js start transactions with snapshot read concern and run several repeated collection scans, asserting the same documents are returned by each query. They do so by saving the results of each scan to a variable prevDocuments (initially undefined) and asserting if prevDocuments has been set that it equals the most recent result.

The problem is that prevDocuments is defined outside of the transaction retry loop, so if a transaction aborts with a TransientTransactionError and is retried with a higher txnNumber, prevDocuments will not be overwritten and may contain the results from a read in an earlier transaction, which the new transaction is not guaranteed to also return (since the test is concurrently modifying documents in the collection). Instead, prevDocuments should be reset within the transaction retry loop to prevent this.



 Comments   
Comment by Githook User [ 10/Dec/18 ]

Author:

{'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}

Message: SERVER-38466 Repeated reads concurrency workloads should reset previous documents before retrying transactions
Branch: master
https://github.com/mongodb/mongo/commit/9eb792842f125e3f087e9fa7b197eec5733739c0

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