Programming Entity Framework, 2nd Edition

Chapter 23. Planning for Concurrency Problems

Concurrency issues are the bane of data access developers. In any sizable organization, it is not uncommon for multiple users or services to be processing the same sets of information. Not infrequently, different users may be updating the same piece of data concurrently, and a conflict occurs. For instance, a salesperson could be modifying a payment at the same time an accounting system is processing it. Or a scheduler might delete a calendar item while another person in a different department was in the middle of editing the same item.

These are two very different types of concurrency problems. In the first problem, you need to consider whose changes are saved. Does the accounting system rule over the salesperson, or vice versa? Do you simply take the last changes that were sent to the database, overriding the changes that were just saved moments ago? In some organizations, the focus is on a single record, whereas other organizations might get as granular as worrying about which fields in the record were updated by whom.

Another common type of concurrency problem occurs when a user tries to save changes to data that no longer exists in the database. What do you do then? You might minimally want to inform the user about the problem and give her an opportunity to take further action, if she has the proper permissions.

It is a tangled web of conundrums and decision making on the part of the application designer. Once your organization has ...