Forum - qupdating collisions

qupdating collisions

Paul Timms

2-20-26

Operating system: macOS

I've found an issue which I'm trying to find the best way to resolve.

An integrated proof of delivery system sends two pieces of data to the SERP API, in two separate calls - let's call them datasets A and B. Both of these read an existing, not OKed delivery and perform an update.

I've designed the majority of the code to be non-updating. Only the writing to the delivery is qupdating. But I have a problem when the two API calls occur within a second or two of each other. Dataset A reads the delivery stored on the server, copies it, makes some updates, and stores it. But, if dataset B reads the same delivery before dataset A has stored its updates, it copies the original delivery, updates it, and stores it, losing all the updates from dataset A.

I toyed with the idea of storing a "lock" in a separate register and checking for the existence of it, but this also has to be within a qupdating procedure, so the same issue could arise.

Since I don't want to make this whole function updating, as it would affect users, the only way I can think of is to write the delivery number to a "lock" file on the server, then remove it once the record update has been done. If the other dataset arrives, it will look for this lock file and if present, wait till the lock has disappeared before continuing.

Does anyone have ideas on how else to prevent these types of collisions?

Gatis Jansons

3-19-26

Hi, Paul.
Sounds like you're talking about REST API. And that your are overwriting data with older values if B managed to read record before A finished to update it. Classic conflict resolution case where 2 sides write same field and last writer wins.

1 - Can't you PATCH only the few updated fields instead of the whole record? >> Efficient if A and B updates different fields in the record.

2 - IF integrated app always sends 2 subsequent async calls - can't you put them together in one call? As in both local updates are merged in the app before getting pushed to SERP?

3 - IF calls can randomly sometimes happen "too close" (like 2 users from different devices) working with same record. The right before doing a write call, do one more read call to fetch record's sequence number. If @sequence is the same then safe to update, and if @sequence has changed then fetch new record version and deal with conflicts in the integrated app's side.

4 - Lock is tricky - could do: check lockFlag -> IF true, then try later | IF not then write lockFlag -> read -> update -> if successful update -> remove lockFlag
!! but then should handle "forever/incorrectly" locked cases
!! I would avoid file-approach

---
But you also mentioned non-updating and qupdating which sounds like HAL web functions are the ones receiving web calls (not REST API).
If that is the case, then look in HAL how ComparePosts is used as condition before RecordUpdate.

Back to the list

New Message
Open Questions My Questions