[SERVER-41057] Add non-transactional afterClusterTime find to multi_statement_transaction_atomicity_isolation.js Created: 08/May/19  Updated: 29/Oct/23  Resolved: 21/May/19

Status: Closed
Project: Core Server
Component/s: Replication, Sharding
Affects Version/s: None
Fix Version/s: 4.1.12

Type: Task Priority: Major - P3
Reporter: Judah Schvimer Assignee: Judah Schvimer
Resolution: Fixed Votes: 0
Labels: prepare_testing
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-40700 Deadlock between read prepare conflic... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2019-05-20, Repl 2019-06-03
Participants:

 Description   

afterClusterTime finds don't get killed automatically on stepdown or stepup. To make sure we don't deadlock, adding another state that just runs an afterClusterTime find would be useful. I'm not sure if there are any consistency checks we can add as well or anything we can expect from what the find returns, but just running the command may weed out deadlocks involving prepare conflicts outside of transactions.



 Comments   
Comment by Githook User [ 21/May/19 ]

Author:

{'email': 'judah@mongodb.com', 'name': 'Judah Schvimer', 'username': 'judahschvimer'}

Message: SERVER-41057 Add non-transactional afterClusterTime find to multi_statement_transaction_atomicity_isolation.js
Branch: master
https://github.com/mongodb/mongo/commit/f36aaeddbb86f47a0bd0dff2e541c73b834f05f7

Comment by Max Hirschhorn [ 13/May/19 ]

The multi_statement_transaction_atomicity_isolation.js FSM workload runs a find command inside a multi-statement transaction with afterClusterTime (because the session was started with causalConsistency=true) over the entire collection.

Per an in-person discussion with Judah, I think we'll want to read ever document in the collection in order to maximize the likelihood of hitting a prepare conflict.

I'm not sure if there are any consistency checks we can add as well or anything we can expect from what the find returns, but just running the command may weed out deadlocks involving prepare conflicts outside of transactions.

I agree there isn't much that's useful to assert about the state of all of the documents because we've lost the guarantee they're from the same snapshot. Since we're doing a collection scan we can at least say there should be this.numDocs of them.

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