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.
In reply to Re^3: How to deal with data race issues with Perl? (standing still for races)
by ELISHEVA
in thread How to deal with data race issues with Perl?
by halfbaked
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |