For those of you who do not know this, a race condition occurs when there are simultaneous requests from multiple users to change data in a database but there is no mechanism to control which request is to be processed when.
The issue: Glide Tables does not have a lock mechanism to sequentially process requests. A simple example can be taken in the case of an inventory modification request:
Product A has 100 pieces in stock.
Mack, Jack and Jim press a button that increment the stock of product A by 10 pieces each at 11:15:35 a.m on the same day. This results in 3 simultaneous data change requests for the same row’s target column in Glide tables.
The necessary action to occur would be this: Glide tables queues up these requests and processes them one at a time causing the final stock effect to be 130.
What Glide Tables does: Glide tables will update the data by the first request in receives and fulfils. If it receive more requests in that 1-2 second period, they may get lost.
Therefore, Glide tables shows a stock of 110 pieces instead of 130 pieces, causing cascading failures through out an app.
It would be immensely useful especially for apps like online stores, ticket bookings and other apps which receive bursts of requests within a period of a few seconds.
I know but that again becomes a job for people who actually know code and data structuring. If GlideApps enables people with no code abilities and just an idea to build an app, they may not be able to build this.
For them, it becomes an unsolvable problem that results in critical data loss.
Firstly, in my experience problematic race conditions are the exception rather than the norm. In almost 3 years building Glide Apps, I could count on one hand the number of times they’ve become a problem and I’ve had to implement a workaround. But, that doesn’t mean you should ignore the possibility, because you can get bitten quite badly when it does happen. So it’s something you just need to be aware of.
Secondly, I guess the fact that this exists is probably an artefact of the way Glide was originally architectured. That is, with all updates happening client side (instead of a more traditional client<->server model), there always exists the possibility of collisions.
I do know that Glide are aware of this limitation, and maybe they have a plan to address it. I don’t know, but I can imagine that addressing it could be a non-trivial exercise
Completely agree with all being said so far. As @Darren_Murphy pointed out, only way around it we’ve found is to use a third party tool.
Similarly, if your app has a form that writes to a log AND that log is used to limit user activity based on first-come-first-serve submissions (think booking forms, scheduling, reservations, etc), then Glide also has the potential to “overbook” in the event that multiple people enter the form at the same time before the condition is met to prevent access to the form.
Side note, just wondering why I’m tagged in this post? Happy to give my two cents, but I don’t work for Glide— I can’t do anything to solve Race conditions.
@Robert_Petitto Just needed your word on it too Robert. You seem to know a lot about Glide’s integration capabilities. I was hoping you could provide insight on how to manage avoiding race conditions using a third party app and glide’s api
