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
Hi there, Server – tried both Windows Server 2022 and Linux Version - 2025-08-11 and 2026-05-25 We were testing a new version (2025-08-11) with a Halcust that we had migrated from the existing ...
10:11 4 Aug 2026
Kevin Stepper
Hi, years ago we used to have the email and conference module. Did not need it so we dropped it. We hav recently implemented global users, which are all named users and therefor seem to need a m...
18:07 3 Aug 2026