Learn about optimistic concurrency and how it prevents lost data writes.
Optimistic concurrency assumes that multiple transactions can frequently complete without interfering with each other. Connect v2 Catalog and Labor resources support versioning to enable optimistic concurrency.
Applications that integrate with these Connect v2 APIs should assume that when a resource is retrieved, it is the current resource. That resource can be updated and written back. After a resource update request succeeds and the new current version is returned, instances of the resource on other clients are stale. An application should treat the failure to update a stale resource as a concurrency exception.
For example: 2 client endpoints get the same catalog item and then both clients try to update it. Client A modifies the item and sends an update which succeeds and increments the item version number. The item update request from Client B will be rejected because the item that it got is now stale. To correct the problem, Client B re-gets the item, updates it, and sends a new update request.
Two clients are trying to update the same catalog item at the same time. The first client updates the item description and writes it back. The second client tries to write back an update on the same item, gets a concurrency error, re-gets the item and writes back an update.
Client A gets catalog item, "Drip coffee".
Client B gets the same "Drip coffee" item.
Client A changes the item
descriptionto "Filter coffee" and sends the update, which increments the item version.
Client B tries to update the now stale "Drip coffee" item
The Client B update request fails with a
Client B gets the current version of the "Filter coffee" item and changes the
falseand completes an update of the item, incrementing the version.
When updating a Connect v2 resource with a
version field, updates will fail on
PUT if a client endpoint has modified the value of the
version field of the