Typically you want concurrency checks to be based on something managed by the database (rowversion and xmin being the go to options) rather than timestamps, bec

Typically you want concurrency checks to be based on something managed by the database (rowversion and xmin being the go to options) rather than timestamps, because timestamps can lie. IME at least, last modified timestamps are usually more like a record of "has this record logically changed" rather than a literal "has the row been modified," so it's not unusual to have things like internal data operations that modify a row without setting the updated timestamp. The ETag header [0] is meant for carrying this info, but TBH I don't think I've ever actually seen it used. Most of the time resources that need concurrency checks end up carrying around a version property or something similar. The back end really has to make the determination of what resources need protection from concurrent updates and enforce it, because of the above and because if you're going to let the client decide whether or not to participate in concurrency checks you really end up with no protection at all. 0: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ET...