Pertti, thanks for the age/retirement example.

I'm wondering where you'd apply those rules- in a middle tier/BO or at the database? It would be safest at the database to make sure that split-second-apart saves don't break the rule. Either that or you'd need to semaphore the tier/BO managing the save, which would need to pull current data and apply changes against it for validation. Personally I'd be inclined to perform validation at the database.

I take your point about the annoyance if somebody else sneaks in and marks a user "retired" while you are trying to reduce the age. Unless the new "retired" value is updated on screen, it wouldn't be much fun. KG also gave an example of an insurance company that presumably has the same sort of issue.

I'm not convinced that this forms a rationale to use pessimistic locking all the time, however.

IMHO it's best to implement change tracking and selective updates all the time. If you need pessimistic locking, add it over the top- not using row locking, but a roll-you-own technique using a lock table with compound indexes.

Using the above technique, you can provide either optimistic or pessimistic locking using exactly the same classes, with no troublesome reverse-engineering to introduce alternative functionality after the event. The optimistic technique still works beautifully when you've wrapped it in a lock. If a customer using optimistic locking changes their mind and wants pessimistic locking for a specific screen, you can probably add that using a separate xml settings file.

This is why I'm so interested in change tracking. IMHO it's *the* place to start, even if people feel they don't need it today because they use pessimistic locking. IMHO there's no downside to sending up just the "retired" flag if that's all the user edited. It's neither necessary nor desirable to save the entire row just because you've got a pessimistic lock. IMHO.