4 ms·
Nope, they're very different things. Database transactions protect you against data corruption if two commands try to modify the same row at the same time. Co
by Merad 4y ago
Nope, they're very different things. Database transactions protect you against data corruption if two commands try to modify the same row at the same time. Concurrency checks (which are arguably poorly named) prevent changes from being overwritten because someone attempts an update based on stale data.
Imagine that you're using an app to manage customer information. For whatever reason you need to update Jane Doe. You pull up her records and start to make the change, but then realize you're late for a meeting. Afterwards, you finish your changes but you notice that someone accidentally entered her name as lowercase ("doe"), so you correct it and save. Cool! Except it isn't cool, because while you were in your meeting she called in to change her name because she got married and is now Jane Smith. You just reverted her back to Jane Doe. If the app included concurrency checks, it would've used something like the SQL Server rowversion column type or the Postgres xmin system column to detect that Jane's data had been modified after you loaded her user record, and you'd have gotten an error prompting you to refresh the page and make your changes again.
It's one of those things that happens a lot more often than you might think in the real world, but yet it's rare enough (or not considered a major problem) so that many apps get away with ignoring it entirely.
- zepolen 4y agoThanks for clarifying, so this isn't about concurrency but rather handling updates based on stale data. I think this really should be up to the client to decide what is required, since there will be cases where the 'nonconcurrent' behavior is in fact expected. In terms of HTTP that would be by using the If-Unmodified-Since header, but yes, it requires server side checks although one can be clever and use a common updated field on all resources.
- Merad 4y agoTypically 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...