The problem of end-user concurrency

by Frans

The problem of end-user concurrency arises when multiple end-users are making changes to shared data.

End-user transactions and database transactions

Traditionally, end-user transactions are mapped one-to-one to database transactions. Although, this is technically the easiest solution, it does not produce the most natural behavour from an end-user perspective. It completely ignores the fact that there are different types of end-user interactions with a system. Some of these types are:

Database transaction are an implementation issue

It should be understood that the notion of (database) transactions is a purely implementational issue. The common example of transfering a sum of money from one account to another account, suggest that transactions are needed for maintaining consistency. They are not. They are the sole result of how a certain database functionality is implemented. The amouth stored on a certain account is the sum of all transactions it was involved in. A database implementation that would store all transactions in a single table would not need any database transactions. (Obvious, from a performance point of view, such a database would not be very well designed.) The amouth stored in the accounts can be viewed as a materialized view.

(To be continued)

Identifier generation

Whenever items are added to a set of data, they usually need to be identified uniquely. The identifier is that what uniquely identifies the piece of data. Either there the identifiers are determined by the end-users or by the system. Both have their own problems with respect to end-user concurrency.

System generated identifiers

There are at least three methods for generating unique identifiers by a system. These are:

User defined identifiers

In this case it is the responsability of the user to come up with an identifier when a new item needs to be added to a database. User defined identifiers are always made inside end-user transactions. There is a possibility that two user, independently of each other, pick the same identifier while they are concurrently adding items to the database. Traditional database transactions only discover non-unique identifiers when the transactions commits. In case end-user transactions are implemented by database transactions, this means that one of the users will receive an error when the end-user transaction is committed, not when the identifier was chosen. Uniqueness of identifiers should trancedent the traditional concept of isolation in database transactions.

(To be continued)

Other Software Engineering articles