Overview

Implement two prototype conflict detectors behind the API from SERVER-138757: an exact reference implementation and the lossy fixed-size hash table described in the architecture doc. Also validate correctness and measure basic performance characteristics.

Background

The architecture doc proposes a hash table H where each bucket holds the max commit timestamp of any approved write that hashes to it. A write set is approved iff no bucket for its keys exceeds the transaction's read timestamp. This bounds memory and trades it against false-positive conflicts. An exact map is needed as a correctness oracle and for debugging. The existing POC adjudicator on conflict-detector-poc is an exact, single-collection, unbounded variant and is reference material only.

Scope of Work

• Exact implementation: map from ConflictKey to last commit timestamp, with GC below a floor timestamp.
• Lossy implementation: fixed-size bucket array (size configurable for testing), initialized to the floor timestamp.
• Prototype a concurrency strategy (e.g. global mutex vs. striped/sorted bucket locking) that preserves recording in oplog slot reservation order. Choosing the final strategy is a finding, not a deliverable.
• Unit tests: disjoint/overlapping write sets, readTs == H[k] boundary, ordering, rejection when commit ts <= read ts, reserveSlot not invoked on conflict, floor handling.
• Randomized differential test: the lossy detector must never return "no conflict" where the exact detector returns "conflict".
• Multithreaded stress test against a sequential model.
• Microbenchmark: throughput and false-positive rate vs. table size and write set size.

Acceptance Criteria

• Both implementations and tests in the project branch; tests pass.
• Findings recorded on this ticket: concurrency strategy trade-offs, benchmark results, false-positive rate observations, and sizing recommendations for a production implementation.

Technical Notes

• Prototype quality; not intended for commit to master.
• Out of scope: commit-path integration (separate ticket in this epic), metrics/FTDC, server parameters for production sizing.