The CollectionWriter (and it's sibling AutoGetCollection::getWritableCollection) paradigms are really an attempt to provide a "see your own catalog writes" semantics for catalog changes performed while holding an AutoGetCollection. This ticket is proposing to implement a proper utility which ensures that all collection acquisitions held by an operation automatically see any catalog writes performed by the code path on which they have been placed.

The semantics of this utility will be:

• It must be instantiated only within a WUOU and its lifetime must be smaller than that of the WUOW
• Must must be instantiated only by passing a ScopedCollectionOrViewAcquisition obtained with at least MODE_X lock on the collection
• On construction must invalidate the ScopedCollectionOrViewAcquisition to guarantee that it is not used while the underlying state is being modified
• On destruction must make visible all the changes made (uncommitted, since within a WUOW) to the ScopedCollectionOrViewAcquisition
• On rollback of the WUOW, must bring the respective AcquiredCollection to the old state (which means any active ScopedCollectionOrViewAcquisitions will start seeing the old state)
•  (FUTURE) On commit must ensure that the committed state presented doesn't advance beyond the Sharding's Placement timestamp

Context

The AutoGetXXX utilities and the CollectionPtr are really caches of a particular collection from the CollectionCatalog, which itself is a cache of the persistent WT state on disk. The CollectionWriter utility serves two purposes:

• Provide a programmatic C++ way to remove the constness of a CollectionPtr
• Establish a "release"-barrier after which any caches of the CollectionCatalog (namely AutoGetCollection(s)) will reflect the changes that were made to the local catalog, pertaining to that collection

The ScopedCollectionOrView acquisition class is really a more complete cache of the entire catalog information for a collection (sharding + local) and at the end of PM-2144, no code paths should be interacting with the catalog outside of ScopedCollectionOrView. The ScopedLocalCatalogWriter described in this ticket will provide the release semantics described above, without dangling memory bugs like SERVER-73755, because it will operate on the TransactionResources' collection acquisitions rather than on stack variables.