Update Services

The term optimistic locking refers to the fact that, in the first place, no locking actually takes place at all, assuming that in most cases no conflicts occur. Instead, for each modification attempt there is a check as to whether a conflict has occurred, and the modification attempt is rejected if need be.

Services for which the first-one-wins strategy is appropriate are called update services. The term “update” indicates that the service provides renewed data, the determination of which has been based upon the data read from the database before.

As explained above, the optimistic locking strategy is to ensure that, of all the service consumers which have read a certain database state, only the first one can commit its updated data. The same strategy can be expressed the other way round as well: Whenever a service consumer wants to store some updated data, it has to be ensured that the data it has read before is still the current data in the database. Otherwise it may have based its data processing on obsolete data.

Change State Identifier

To realize this, the service consumer must be able to indicate which data it has read originally. Therefore, an identifier is assigned to all pieces of data that are to be read, which uniquely identifies the state of the data. This identifier is called change state identifier (CSI). The change state identifier must be guaranteed to change with each database update.

As illustrated in the figure below, the consumer always receives the change state identifier together with the requested data. In a subsequent update request, the consumer can use the identifier to specify the state of the data which the update request refers to. If the specified state is no longer the current state, the update request is denied. In this case, the consumer has to read the new state and repeat the update request.

The sole requirement for a change state identifier is that it must change with each database update. For the enterprise services for the SAP Business Suite, an existing database field will be used if an appropriate one is available (such as a change document number or the time stamp of the last document modification). Otherwise, a hash value generated from the current data is used as the change state identifier. As a hash value can be generated from the current data whenever needed, it does not need to be stored in the database. This is an advantage compared to other possible implementations such as an update counter or an update time stamp.

The consumer is not allowed to interpret the change state identifier. For the consumer, it is a token in the form of an arbitrary character string without semantics, because this allows for the underlying implementation to be changed later on.