Re: How to avoid Race condition in Appsheet?

darpan_sanghavi · 09-01-2021 12:26 AM

I am creating an app on the Seating Management for our offices. Admin can set number of seats for any specific location and employee can book that many number of seat (first come first serve basis)
Now in order to ensure there is no overbooking, I am doing the following,

Check Office Capacity value that Admin has configured
Check already booked record count for one particular day
Subtract (1-2)
If 3 is greater than 0 then only I am allowing new entries, so far so good.

Now the issue arises when multiple users are accessing the App simultaneously.
Assume only 1 place is left for the location and 3 users are accessing the App simultaneosuly. All 3 will see 1 place left and can book the same as there is no validation happening on Actual Save (Submit) form event.

Any thoughts on how to resolve this?

For Tech-Savvy friends : ‘How to avoid race condition in Appsheet?’

Rifad

Maybe you can use an action to navigate to that form view and force sync? You can refer this post META POST: Deep Links & URL Parameters

1minManager

Its a problem you cannot stop, due to the fact Appsheet uses syncing and not a live connection to a SQL database. Turning off Delayed sync will help as this forces a sync after every save. But users will hate it. The only way I got around the issue was to create a bot that ran nightly to check for duplicate bookings and then report them so a human could sort them out.

Simon@1minManager.com

1minManager

Steve

Not possible.

darpan_sanghavi

Understood, thanks all for your suggestion/replies.

Hopefully this can be taken as a feature request as there are many use cases which needs to maintain the capacity/values in check.

3millones

A few years have gone by. Is there a solution for this now?

Steve

You could use a bot that chooses the winner.

3millones

What do you mean?

Steve

If a collision occurs, the bot notices and changes something to fix it. If a second row arrives with a duplicate serial number, it's given a new serial number, for instance.

SkrOYC

@1minManager wrote:

The only way I got around the issue was to create a bot that ran nightly to check for duplicate bookings and then report them so a human could sort them out.

This is currently the best option. If you run a bot that checks this every 2 hours or so you can create a system similar to: "Submittion approved, we will send you a confirmation email once we go over our automatic verification system. We want to make sure we can provide you with XXXXX at the specific time frame you need. We take your time seriously. Sincerely XXXX"

Arni_Kli

1) You can link the "Save" button in the form to action of checking for availability of seats before saving (sequence of actions). If there are no free seats left while the form was being filled, then apologize to the user and inform him that there are no more seats.

2) A more advanced approach might be to first save the booking, and after saving check the database for overbooking and determine the final record. If there is an overbooking and this record is final, then delete it and then apologize to the user.

3millones

In my app I have warehouses with products and stock. The issue is when multiple users act upon the same stock record via different actions. For example, a user makes a sale for prod01 in warehouse A. Another user recevies an purchase of prod01 in the same warehouse A. What strategy would you recomend in this situation? What I'm doing no t very happily is running a nightly bot that goes thorough all the actions (sales, purchases, etc) that affect stock, and recreates the inventory. What I dont like is that until the bot runs the data is inconsistent and sometimes users make decisions based on wrong data.

SkrOYC

Run the bot after the Add event occurs then, this will make sure to check against the datasource in the cloud.

General rule, always add a timestamp for creation and changes in your tables, this will help a lot to this kind of cases.
Another one, use UTCNOW() if your app is used in more than one timezone.
Another one, use UTCNOW() even if your users are from the same timezone, just adjust that accordingly IMHO