Lock entities

Use ValueEdge's optimistic locking to make sure API requests do not interfere with each other and to prevent data loss.


ValueEdge uses optimistic locking to prevent data loss when making changes to the same entity concurrently. We recommend you implement this same strategy when working with the ValueEdge REST API.

Use the client_lock_stamp field to facilitate optimistic locking using the REST API. This field tracks only changes that require entities to be locked in order to prevent data loss and conflicts. When these changes occur, client_lock_stamp is incremented. client_lock_stamp is not incremented when changes are made that do not require entity locking.

Note: Not all changes require locking, such as internal server-side changes for the entity or changes that are a result of business rule execution on the server-side.

Examples of changes that do not require locking include: Changes to positional attributes (index in the grid), and some relations between entities that are read-only in the entity's Details pane, like hierarchical relations.

The version_stamp field is incremented for all changes on an entity, including changes that do not require incrementing the lock stamp. Having both the version_stamp and client_lock_stamp fields lets ValueEdge perform updates without unnecessarily locking data.

To validate the correctness of the client data and avoid accidental overrides, send the client_lock_stamp field in all update (PUT) requests.

The server then validates the version and returns 500, Internal Server Error, if there is a mismatch.

If you do not send the client_lock_stamp as part of the update request, the server does not validate.

Back to top


Here are examples of locking the entity while updating it.

In both examples, the client_lock_stamp is sent as part of the request.

Back to top