Hi all. We are trying to create a meeting room booking solution where it should be impossible to book the same meeting room on the same time. We are currently trying to achieve this by isolating this function to a webservice. One solution would be that the webservice would queue up all requests coming in and process one at a time. The combinations of using “No Concurrency” and “Run Async” does not seem to yield the right result. In a SQL server approach, I would solve this by using a stored procedure that only inserts the new booking if there are no bookings in the time slot in the database.
How to best solve this in APPFarm?
Any feedback is appreciated
Hi Yassine and thank you for your reply. The “unique” approach could work if there are consistent periods. The bookings may pass into a period, pass out of a period, pass through a period, and reside inside a period. I dont quite see how that would work with this complexity. Could you elaborate more on your idea for the solution given this?
Indeed, booking duration flexibility adds complexity to the solution.
This may require some compromises on your end if the easy solution is not working.
A couple of key questions:
Is it necessary to keep “Run Async” enabled?
Is there a defined minimum booking time?
On top of my mind, If a minimum booking time exists, one possible approach is to split reservations into fixed intervals (you can visually adapt it for the customer to look like one block )
Since Booking 2 (A-14032025-0930) already exists, a uniqueness constraint will trigger an error.
What you must do:
Persist all three bookings together ( not seperatly).
If any of them fail due to a uniqueness constraint, Appfarm will reject the entire transaction. (you will not have Booking 1 and 3 in your DB)
Catch that error and handle it to normalize it for your customer
Other info :
it is a bit complexe to do it like this, and there is probably a better solution for that
in order for you to handle it easily, you can imagine having your uniqueness constraint in another table. for exemple
– a main DB Booking that will have all your basics info
– a linked DB Booking Slots that will contain all your slot with your constraint
In our exemple it will be
One Line in Booking
– ID 123456
– Booked By *****
– Booking Start 14/03/2025 09:00
– Booking End 14/03/2025 10:30
– Booked Room A
Have you considered building 2 endpoints, where
Endpoint 1 is “no concurrency” for internal DB consistency and then
Endpoint 2 which is not and act as the que and is the “public” booking endpoint
The 2 service can hold parallel incoming booking request with a sleep logic if concurrency error.
The 1 service has logic ensuring consistent database while the 2 act based on response from 1. I assume that this logic will not be overrun with bookings?