Lost updates

Business processes often span multiple Cloud API calls. When this occurs, the first call is typically either a GET that retrieves data or a POST that creates data. A later call may attempt to modify the resource queried for or created in the initial GET or POST.

Some other process could modify the resource between the GET/POST and the subsequent attempt to modify it. For example, suppose:

  1. A caller application GETs activity xc:20. The activity's subject is "Contact additional insured" and the priority is Normal.
  2. An internal user manually changes the subject of activity xc:20 to "Contact primary insured" and sets the priority to Urgent.
  3. The caller application PATCHes activity xc:20 and sets the priority to Low.

The caller application's PATCH overwrites some of the changes made by the internal user. This could be a problem for several reasons:

  • The caller application's change may be based on the data it initially retrieved. The caller application may not have initiated the change if it had known the subject or priority had later been changed by someone else.
  • The internal user may not be aware that some of their changes were effectively discarded.
  • The activity may now be in an inconsistent state (such as having a subject that is normally used for urgent activities and a priority of Low).

This type of modification is referred to as a lost update. Within Cloud API, a lost update is a modification made to a resource that unintentionally overwrites changes made by some other process. You can prevent lost updates through the use of checksums.