[SERVER-47204] Get rid of OperationContextNoop Created: 31/Mar/20 Updated: 29/Oct/23 Resolved: 28/Jun/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 7.1.0-rc0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Kaloian Manassiev | Assignee: | Kaloian Manassiev |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | PM-2144-Milestone-0, auto-reverted | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Assigned Teams: |
Sharding EMEA
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Sprint: | Sharding EMEA 2023-06-12, Sharding EMEA 2023-06-26, Sharding EMEA 2023-07-10 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Linked BF Score: | 156 | ||||||||||||||||||||
| Description |
|
The OperationContextNoop was introduced long time ago as means to abstract lock acquisitions and access to the recovery unit for unit-tests (and MongoS). With the unit-testing tools that we have now, such as ServiceContextTest, this seems to no longer be necessary, so we should try to get rid of it. The most usages seem to be in the Execution Team's test code, so I am assigning this ticket to their backlog. |
| Comments |
| Comment by Githook User [ 03/Jul/23 ] |
|
Author: {'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}Message: |
| Comment by Githook User [ 03/Jul/23 ] |
|
Author: {'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}Message: |
| Comment by Githook User [ 29/Jun/23 ] |
|
Author: {'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}Message: |
| Comment by Githook User [ 28/Jun/23 ] |
|
Author: {'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}Message: |
| Comment by xgen-buildbaron-user [ 26/Jun/23 ] |
|
Ticket re-opened due to revert. serverless began a consistent failure of src/mongo/db/modules/enterprise/jstests/serverless/native_tenant_data_isolation_simple_FLE2_dollar_test.js |
| Comment by Githook User [ 26/Jun/23 ] |
|
Author: {'name': 'auto-revert-processor', 'email': 'dev-prod-dag@mongodb.com', 'username': ''}Message: Revert " This reverts commit c89b4c97cb05623319444d9f96f2b99ddefdc155. |
| Comment by Githook User [ 26/Jun/23 ] |
|
Author: {'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}Message: |
| Comment by Githook User [ 19/Jun/23 ] |
|
Author: {'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}Message: |
| Comment by Githook User [ 14/Jun/23 ] |
|
Author: {'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}Message: Combined with operation_context_non_d it obviates the need for any tests to have manual initialisers for the OperationContext and is the final prerequsite for removing the remaining usages of OperationContextNoop and LockerNoop. |
| Comment by Githook User [ 05/Jun/23 ] |
|
Author: {'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}Message: |
| Comment by Githook User [ 02/Jun/23 ] |
|
Author: {'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}Message: |
| Comment by Connie Chen [ 01/Mar/21 ] |
|
We no longer use OperationContextNoop for storage engine initialization, work expected in this ticket would be to remove it from testing. |
| Comment by Louis Williams [ 31/Mar/20 ] |
|
Yes, that's my understanding. We need a RecoveryUnit to read from the durable catalog to perform initialization, but the storage engine hasn't been registered on the ServiceContext to create a RecoveryUnit. Related to |
| Comment by Kaloian Manassiev [ 31/Mar/20 ] |
|
We should be able pass a regular OperationContext instead to this constructor. Or is this a chicken-and-egg problem between creating a RecoveryUnit being necessary while the storage engine is being constructed? Because if that is the case, then storage engine loading shouldn't rely on the RecoveryUnit at all. |
| Comment by Louis Williams [ 31/Mar/20 ] |
|
We rely on OperationContextNoop forĀ storage engine initialization, not only testing. |