One important question in web applications that share resources as database is solving concurrency problems. Very often it happens that one actor can change resources already modified by other actors, in a way that is no evident client-side. Lets assume that two operators, Alice and Bob, try to assign a value to a field F. If concurrency is not treated and Alice wants to set a value X, while Bob wants to set a value Y, the first update is lost, so the last updater wins. This problem is defined as "lost updates". In order to avoid lost updates, there are two ways: pessimistic lock and optimistic lock.

When using pessimistic locking, a web app designer is pessimistic about the chance that at the same time two operators would like to change the same record in a database and so it locks the access to the resource until one operator has finished any change on it. This technique is a bit difficult to implement and needs to rely on database locking features.

When using optimistic locking, a web app designer does not lock the record until it is modified. In order to avoid "lost updates" problem, at every change of a record it is necessary to verify if it has been modified in the meanwhile. If this is true, the update command has to fail and the user should receive a notification with the updated field. This can be frustrating for the user but avoids lost updates without interfering with the ability to see resources. This pattern has be implemented in a simple way in Ruby on Rails.

Pessimistic locking is more effordable, but it constrasts concurrency, reducing efficiency on the system. Optimistic locking is more appealing when there is a lot of concurrent calls, but can be frustrating. In my opinion, your choice depends on what type of web app you are building.

Categories: misc, progr