Sure, there are a lot of cases where I'm not allowed to make changes, regardless of whether others are making similar changes at the same time or not. But what you originally described was that resolution of races in updates would be based on author standing. I don't see where your reply above validates that scenario and I still find such a mechanism nonsensical.
When you get to financial data, you can easily end up doing two-stage commits. But there you are far away from the web-based, optimistic locking where composing the update can take a long time, wiki-like, loose system that was under discussion. And there, the transaction that doesn't detect a conflict goes through and the transaction that does detect a conflict is denied. There is no "push this conflicted update through because the author has higher standing than the author of the conflicting update" because that would violate transaction integrity.
- tye
In reply to Re^4: How to deal with data race issues with Perl? (standing still for races)
by tye
in thread How to deal with data race issues with Perl?
by halfbaked
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |