What are the use cases under which we need to be acquiring a POS while holding a lock?
Thanks kaloian.manassiev@mongodb.com, I can't speak for all use cases where we're holding locks but the two we've had come up in resharding are:
- Updating the in-memory state of the corresponding ReshardingCoordinator instance on storage transaction commit when a participant shard writes to the config.reshardingOperations collection. (
SERVER-61482, SERVER-49572)
- Updating the in-memory state of the corresponding DonorStateMachine instance to track when a read or write operation came in while the sharding critical section is held for the namespace. (
SERVER-64372)
Maybe for (2) it would be preferable to increment the counter in service_entry_point_common.cpp after locks, storage engine snapshots, etc. have already been released.
An alternative to (1) which I think Esha had proposed in the past would be to have a decided command for participant shards to run on the config server primary to update the config.reshardingOperations collection and then not as an OpObserver update the ReshardingCoordinator instance in-memory state. As part of the Global Index Coordinator we can see about doing away with some of the complex work which happens in an OpObserver.
|