Concurrent Data Update in a Space

When multiple processes concurrently get and update tuples in a space, two processes might try to update the same tuple at the same time. In that case, it is often necessary to serialize updates.

The classic example of this scenario is that of a bank account balance: if a deposit and a debit to the same bank account are being processed at the same time, and if each of these operations follows the pattern “get current account balance, add/remove the amount of the transaction, and set the new account balance,” both transactions might start at the same time and get the same current account balance, apply their individual changes to the account value, but the application that is last to set the new account balance overwrites the other applications’s modification.

There are two ways to solve this problem using ActiveSpaces:

An optimistic approach is best when the likelihood of having a collision is low. In this case, you should make use of the space’s update method, which is an atomic compare and set operation.

This operation takes two parameters, one representing the old data that was retrieved from the space, and another one representing the new version of that data. If the old data is still in the space at the time this operation is invoked, then the operation will succeed. However, if the data in the space was changed in any way, the operation will fail, which indicates that your application should refresh its view of the data and re-apply the change.

A pessimistic approach to the concurrent update problem is best when there is a high likelihood of more than one process trying to update the same tuple at the same time. In this case, application programmers should first attempt to lock the tuple, and only apply their update to it after having obtained the lock. Locking is described in the following section.