Take the following sequence of events:
- Business layer requests data
yfrom data layer.
- Data layer returns version 1 of
- Business layer starts performing logic based on data
- Another (concurrent) operation updates data
xto version 2.
- Business layer instructs data layer to save new data
zbased on logic at step 3.
z saved in step 5 has now been saved based on inconsistent, or "stale" data. The data
x became stale during the business transaction. Say for example, data
x holds a flag indicating whether the creation of
z data is permitted.
In past I've seen this issue dealt with by:
- Tightly coupling business logic with data operations. For example, business logic in RDBMS stored procedures, or application code co-mingling logic with persistence-aware data operations. or;
- Ignoring the issue because the likelihood x impact = too low to be concerned with.
My question: is there a viable 3rd option? Something that ensures consistency while maintaining a healthy separation of concerns between the business and data layers.
Is this something that ORMs address? I know they'll deal with optimistic concurrency for data writes, but I'm not wanting to update data
x, just ensure that nothing else has updated it during the course of the business transaction. Or more specifically, that the "is
z creation permitted?" flag hasn't been updated.
For any platform-specific answers or comments, I'm working with C# and Postgres.