rsbaker0:
We started with a similar application migration and have avoided locking entirely.
There are several ways to implement concurrency, but we have chosen to implement what we call "changed values concurrency" and not do any locking. First change to a field from a loaded object "wins", any others result in a concurrency exception when the "stale" but changed object is saved. However, two users can independently update separate fields in the same object and both updates can succeed.
We chose this approach mainly because it requires no database-specific features (e.g. timestamp columns), nor does it require any alteration of the database schema. Also, the odds of two users really wanting to edit the same object are low because of the way the data is partitioned, so we mainly wanted to ensure integrity of the data. This approach works well except for contrived situations (e.g. one user updates city, another updates zip code).
Suppose this concurrency situation happens:
User A
- changes property StreetName (Elmer St. -> Fudd St.)
- everything is valid, namely the DoorNumber 1001 (this door number exists on both the Elmer St. and Fudd St.)
User B
- changes property DoorNumber to 1101
- everything is valid, namely the StreetName (Elmer St. door numbers go up to 2000)
The problem is Fudd St. door numbers only go up to 1050...
So User A change is valid and User B change is valid but the combined result of both changes makes the address invalid.
How do you handle this problem?
Copyright (c) Marimer LLC