[SERVER-52877] Use WUOW in write ops under global write lock Created: 16/Nov/20  Updated: 29/Oct/23  Resolved: 05/Apr/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.0.0-rc0

Type: Task Priority: Major - P3
Reporter: Henrik Edin Assignee: Henrik Edin
Resolution: Fixed Votes: 0
Labels: techdebt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-63889 Remove CollectionCatalog::LifetimeMod... Closed
Related
is related to SERVER-63888 Make oplog collection copy-on-write i... Backlog
is related to SERVER-51199 Investigate whether repair needs to o... Closed
Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2021-12-13, Execution Team 2022-02-21, Execution Team 2022-03-07, Execution Team 2022-03-21, Execution Team 2022-04-04, Execution Team 2022-04-18
Participants:

 Description   

While not necessary for correctness as there can't be any concurrency going on it would be a nice cleanup to not have multiple modes that we need to support throughout the code base.

For example, the collection catalog exposes a way to bypass the copy-on-write system to do collection modifications directly on the instances installed in the catalog (the inplace mode). Having modes like this is prone to error and misuse so it would be better if there was a single way to do these kind of writes.



 Comments   
Comment by Githook User [ 05/Apr/22 ]

Author:

{'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}

Message: SERVER-52877 Unify how writable Collections instances are handled

CollectionCatalog::LifetimeMode has been removed. Catalog writes now
require that we are in an active WUOW.

Make it allowed to use WriteUnitOfWork when the server is in readOnly
mode. It does not open storage sessions, just allows registration of
RecoveryUnit callbacks that are executed when calling commit(). This
allows for the unification of code where we need to initialize Collection
instances even in readOnly mode.

Handling of enforcing readOnly has been pushed down to the RecordStore.
All interfaces that perform write now check if we are in readOnly mode
and throw if we are.

Catalog updates using the BatchedCollectionCatalogWriter class bypass
the Collection cloning if the batched CollectionCatalog instance already
has a uniquely owned copy (a previous write to this collection has been
requested). It is also not required to be in an active WUOW when the
BatchedCollectionCatalogWriter is used.
Branch: master
https://github.com/mongodb/mongo/commit/fa32d665bd63de7a9d246fa99df5e30840a931de

Comment by Fausto Leyva (Inactive) [ 14/Dec/21 ]

Upon adding WriteUnitOfWork to the cases where we accessed a WritableCollection with the InPlace mode, we hit an assertion in the constructor of WriteUnitOfWork from DatabaseImpl::init() in cases where we run mongod with storageGlobalParams.readOnly set to true. It turned out that the read-only mode used the code path through repairAndRecoverDatabases() and depends on the InPlace mode to not use WriteUnitOfWork. We could create a new RAII type similar to WriteUnitOfWork class but designed specifically for read-only cases, but it defeats the purpose of the ticket which is to reduce special handlings. Putting the ticket back to backlog since it may not simplify the code how we had liked.

Generated at Thu Feb 08 05:29:16 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.