Atomic operation

data
(Yossi Oulu) #1

Assuming I would like to develop a simple booking app. list of rooms and users that can book a room.
Although I know how to develop it, I have a general question about multi user and appsheet architecture.
Is there a way to ensure that two users will NOT book the same room, just because they did the booking at the same moment when the room was free? Because Appsheet does the change locally and syncs later, how can this update conflict be identified and prevented?

(Reza Raoofi) #2

I do not think with current architecture which allows for offline data updates you could prevent double booking, unless the booking happens only by one user, or by one device.

1 Like
(GreenFluxLLC) #3

You could allow double-booked requests though, just don’t allow the user to proceed with the booking. Try creating a slice that contains only the room number and date, then create a form that allows users to submit a request to book a room.

Then setup a workflow to approve the request for booking IF no other requests for that room exist for the day. That way the check is done on the server, and only unlocks the request for booking on the first request for the day. A [Status] column could track the progress (“Requested”, “Booking”, “Booked”) and be used as your filter condition for the workflow and slice.

1 Like
(Yossi Oulu) #4

Thanks. Just to add, even when the check is done on the server you need a specific atomic operation to prevent two from booking on the same moment. I think the way to get this atomic operation is by checking the [_THISROW_BEFORE].[requesting user] and [_THISROW_AFTER].[requesting user]
Only once the ‘before’ will be empty and the ‘after’ is not empty. This is the user that “won” the room.