[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: |
|
||||||||
| 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:
DDL thread: This thread must perform the following operations on ddlcoll:
|
| Comments |
| Comment by Githook User [ 28/May/19 ] |
|
Author: {'name': 'Tess Avitabile', 'email': 'tess.avitabile@mongodb.com', 'username': 'tessavitabile'}Message: |
| 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. |