Dealing the future with commands

Consider a scenario where we have a CRUD application over the Internet backed by a relational database. One of the big issues in this scenario is concurrency.

There is no connection open to the database, so we cannot lock record(s) to avoid concurrency problems. If we had the connection, we can limit concurrency with exclusive access to that record.

So, we need to deal with optimistic concurrency. Create a snapshot of the records (marked as original records); change data with the client application; then send it back to the Web. What could happen? If another user performs the same operations at the same time, starting from the same copy of the data, the application can do two things:

• If only the ID is used to query the original records to update (and this practice is used more times than we could imagine), the second user updating wins and overwrites the changes of the first user because the app has no way of knowing that there is concurrency. The first user...