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?
Leave Comment
You can subscribe to notifications for this post by selecting the 'star' icon on the top right corner of the post.
Latest Posts
Paul Timms
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 c...
17:59 20 Feb 2026
Andis Blicāns, Grasko
There are some topics in this Q&A related to this question, but none of them is about Idle users - Concurrent or Named. If timeout minutes are specified in Optional Features, then all idle users are...
15:53 18 Feb 2026