Problem

SERVER-123415 added a lock-free atomic shadow of the lastApplied timestamp to ReplicationCoordinatorImpl so that computeOperationTime – invoked on every command response to populate the operationTime field – no longer acquires the ReplCoord mutex.

ReplicationCoordinatorDisaggregatedStorage is a parallel implementation of the repl::ReplicationCoordinator interface and never received the same treatment. It falls through to the interface default getMyLastAppliedTimestamp() = getMyLastAppliedOpTime().getTimestamp(), which acquires _oplogManagementMutex on every read command via computeOperationTime (service_entry_point_shard_role.cpp).

Solution

Mirror the SERVER-123415 pattern in the disaggregated storage coordinator: add an AtomicWord<unsigned long long> _lastAppliedTimestampShadow, update it under _oplogManagementMutex wherever lastAppliedOpTime changes (the apply path and resetMyLastOpTimes), and override getMyLastAppliedTimestamp() to read it with loadRelaxed() – removing the mutex from the per-request response path.

Correctness

Same rationale as SERVER-123415: the shadow is written under the lock in the same code path as the authoritative value, so maximum staleness is sub-microsecond. A stale read returns a timestamp <= the authoritative value; since operationTime drives causal consistency, a slightly older value only affects visibility of other clients' concurrent writes, which is already non-deterministic due to replication lag.

Notes

Found while investigating BF-43331 (disaggregated vs classic storage throughput). This optimization does not by itself close that throughput regression, but it removes a per-read mutex acquisition on the disaggregated read-response path that the classic coordinator already avoids.