-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Labels:None
-
Storage Execution
In theory, this should not be too difficult, but would take some work.
Multi-document transactions save the RecoveryUnit (and thus snapshot) and locks held (LockerImpl) across operations/commands. Lock-free reads store the CollectionCatalog on the opCtx, so any new collections accessed can be from the same point-in-time view of the catalog: we would need to save this for the multi-doc transaction like the RecoveryUnit and LockerImpl is saved today.
The part I'm unfamiliar with is how storage snapshots are handled in multi-document transactions, whether they can ever be reset. If snapshot resets happen, then that would make it a little trickier to handle a stored CollectionCatalog – the CollectionCatalog would need refreshing, too, to maintain the same catalog view in-memory and on-disk.
- is depended on by
-
SERVER-62602 Remove unnecessary durable catalog reads for multi-document transactions
- Backlog