Update Resources Using Concurrency Control

What should happen when multiple apps and users can edit the same resource at the same time? Which app’s data is actually saved? The one who saves first or the one who saves last (other possibilities exist)?

In Noah ES it has been decided that the App that saves data first “wins”. When the other App saves data it will receive a proper error code.

In order to achieve the above, optimistic concurrency control (also known as optimistic locking) has been implemented.

The HTTP protocol supports a HTTP header called an ETag (entity tag) that typically is used to check if a resource has changed.

When a resource is fetched (get operation) the ETag header (with a proper value) will be set as part of the response.

Note that no ETag will be returned if GET’ing an entity, but applying exclude-filters. This is to prevent later PUT operation with only the partially retrieved entity.

If the resource later is going to be updated (put operation), the If-Match header must be added to the Request Header. The value must be the earlier received value of the resources ETag. When the resource is going to be updated the contents of the If-Match header will be compared with the server’s Etag value of the resource. If they match the record will be updated, if not the “Precondition failed (412) HTTP response will be returned to the App.

An App can check if a resource has been updated using the If-None-Match header. The contents of the header will be the earlier received Etag value. When the server receives the request the value of the If-None-Match Header will be compared with the value of the server's resource. if they match the server will return the HTTP response “Not modified (304)“ i.e. no changes have been made to the resource.

The above is applied to all resources.