4 ms·
No, the point is avoiding conflicts where possible. Cases like "users concurrently update the same property in the same object" are rare in real life.
by ComodoHacker 5y ago
No, the point is avoiding conflicts where possible. Cases like "users concurrently update the same property in the same object" are rare in real life.
- noduerme 5y agoNo, this is what row-level locks are for. And concurrent updates happen all the time in real life. This is why every DB in (serious) production has transactions and rollbacks. It happens all the time. If you're not aware of concurrency issues on your DB or your mid-level backend code isn't equipped to handle them, you're writing bad code indeed.
- ComodoHacker 5y agoPlease reread the "same property in the same object" part. You need row+column level locks for that. In cases where users update the same row but different [independent] columns, you can avoid unnecessary conflicts. Either by redesigning relational model or by using CRDTs.