Commit and prepare timestamps are not supposed to be set after any active read timestamp in the system. This is checked in HAVE_DIAGNOSTIC builds, and includes acquiring the global transaction lock.

Ideally, we would always do the check and without locking the global transaction structures.

We should investigate if we can track the current largest read timestamp on the system. As this is not required to be a definitive check, it's only "best efforts", we wouldn't need to lock or atomically CAS the "current largest read timestamp" value, instead we could let it race (and live with an increased number of cache shootdowns).