[SERVER-41107] Create concurrency test that accesses a collection in a transaction after catalog changes Created: 13/May/19  Updated: 29/Oct/23  Resolved: 28/May/19

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

Type: Task Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Tess Avitabile (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-40352 Transactions that perform untimestamp... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2019-05-20, Repl 2019-06-03
Participants:
Linked BF Score: 50

 Description   

Transactions with local readConcern perform untimestamped reads and do not check the min visible snapshot for collections, so they can access collections whose catalog information does not match the state of the collection in the transaction's snapshot. We will write a concurrency test to exercise this behavior and ensure it cannot cause crashes.

Transaction thread: This thread must perform transactions using local readConcern. It starts the transaction with an operation on a collection startcoll. Then it performs operations on a collection ddlcoll, which may have had catalog changes since the transaction's snapshot was opened. These operations must include all operations that are supported in transactions (except killCursors, which does not touch data) and must make use of indexes:

  • find (collection scan)
  • find (index scan on _id)
  • find (index scan on secondary index)
  • aggregate
  • delete
  • distinct
  • findAndModify
  • geoSearch
  • getMore
  • insert
  • update

DDL thread: This thread must perform the following operations on ddlcoll:

  • Create
  • Drop
  • Rename
  • Create secondary index


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

Author:

{'name': 'Tess Avitabile', 'email': 'tess.avitabile@mongodb.com', 'username': 'tessavitabile'}

Message: SERVER-41107 Create concurrency test that accesses a collection in a transaction after catalog changes
Branch: master
https://github.com/mongodb/mongo/commit/f70fb4c734e342afe6561960edd53667f16e9eb1

Comment by Max Hirschhorn [ 16/May/19 ]

All threads running the same FSM workload file receive the same db[collName] namespace to operate on. It is separate FSM workload files that receive different db[collName] namespaces to operate on when running in the concurrency_simultaneous*.yml test suites.

Drawing some inspiration from the agg_out.js FSM workload, you could use db[collName] for one of the collections and then make up another collection name (the pattern is to base it around the FSM workload name) as the other collection. You could also ignore collName entirely and make up both collection names.

As mentioned in SERVER-41061, it seems unlikely that we'll ever run different FSM workloads on the same collection (to increase contention) though it was a goal of the framework originally. Realistically each FSM workload is going to keep receiving its own collection but you may as well continue the pattern of using the FSM workload name as the uniquifier.

Comment by Tess Avitabile (Inactive) [ 16/May/19 ]

max.hirschhorn, do you think it will be possible for me to have different threads in the FSM test act on the same collection? Looking at other FSM tests, I see that the states take the collection name as input, and I don't see a way to express that certain operations should act on the same collection.

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