Simultaneous Update Requests

When two simultaneous requests for updating the same entity are sent, it can cause a conflict, which may result in an incomplete or partial update of the entity.

When you process simultaneous requests that add or update objects in the Reltio Platform, the states of an object: when we are writing the object data into a data storage and when the write operation began - may be different. This situation is called a conflict, and there are two approaches to resolve it:
  1. Apply custom logic. It processes data in such a way that the result is similar to the execution of a single request containing all changes. This is the default behavior.
  2. Resend the request. In this case, the result of the conflict will be as if the requests are executed one after the other. By default, Reltio resends the request a few times in a minute.

In some cases, both approaches produce the same result. For example, if you send two partial override requests, each request updates a unique attribute such as phone number or email address of the same entity. But there could be situations when each approach provides a specific result.

For example, two simultaneous requests are sent:
  • A partial override request to update a nested attribute's sub-attribute, and the enableNestedPartialOverride parameter is enabled. For more information, see Partial overrides.
  • A cumulative update request to remove the nested attribute. For more information, see Cumulative Entity Update.
Now, when the cumulative update is applied, there will be a conflict, because the states of the attribute: when we are updating the attribute data and when the update began - are different. In this case, the first approach removes all sub-attributes except the one that must be updated from the nested attribute, and the second approach removes the nested attribute.

Conflicts may not happen every time two simultaneous requests that update the same object are sent. The first request may begin and complete before the second request, as the second request may spend time on operational needs before it begins. If the first request is completed by the time the second request begins, there will not be any conflict. The result of the operation will be as if the requests were executed one after the other.

Every time the Reltio Platform retries a request, it resets the time given for the retry attempt. If two requests were initiated a few milliseconds apart, and the first request was resent because there was a conflict, then the entity history will show that the first change was applied later. For more information, see Entity History (With Count of Changes).