You paint a scary picture, but also one I've never seen implemented (nor do I expect to ever see such). A system where I'm allowed to update a field but not if somebody of higher standing than me has updated it? ("at the same time"? or just "recently"? or "ever"?) That sounds like a nightmare design and I can't fathom what purpose it would serve. It makes no sense to distill what changes to apply when a race occurs based on each author's standing.

I've seen the requirement in sales support systems and also a campaign finance management system.

In sales systems, I think the requirement is pretty rare. Data can be localized with the potential for update issues when a company uses a travelling sales team with on-site visits, but in that case many sales teams try to have a sole contact person handling financial commitments. Every one else just says - call the account exec. When multiple people are interacting with a client and have some authority to make financial arrangements (i.e. a call center), the data is not normally distributed so the possibly of the main copy and a local copy both changing at the same time isn't a concern. But that is just speculation. I haven't developed a call center system. Maybe some of the larger ones do have multiple physical centers and distributed data.

Campaign finance is another matter. There is per-person limit on campaign donations. I recall about 20+ years ago designing a system for congressional campaigns. Transactions could be entered locally by an on-site team, but the donation wouldn't get posted to final central accounts unless the donors total was below the minimum. Instead a notification was sent to the campaign finance officer. Officially authority level allowed one to resolve the problem by choosing one donation and rejecting another, by returning a check, or by sending a letter explaining why the pledged amount had to be reduced. What actually happened was another matter. (We called it the sleeze module).

But today, this situation likely would not occur (sleeze aside) because it is nearly trivial to just have a central web application and set up the fund raising event with an internet connection. Back in the 1980's data needed to be distributed because transferring data at 300 baud is SLOW. it wasn't practical to set up dedicated T1 lines at each and every travelling campaign event. Off-line distributed systems and ugly merge processes were the result.

Timing issues aside authority based updating rules are not uncommon in financial systems. Another system I was involved in had a rule whereby expense account transactiosn would be rejected (and sent onto the boss) based on the person's authority level, the amount of the expense, and total amount of expenses posed in the last week or month. The failed posting could be overridden by the boss.

Looking over these examples, I think timing+authority based requirements are more likely to occur when adding/removing records to a set of child records rather than when values are changed in a non-derived field on the parent record. Multiple child records are much more likely to come from a variety of distributed sources than normalized data on the parent. If there is one "thing" it is possible to assign one person to manage that one thing ("ask the account exec") and give them sole editing rights.

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