This will not work - as every device thinks it has the sole truth. The last one in over-writes the previous user’s input. And even if you use a timestamp, you can lock all users by forcing all of them to wait (and I did this in one iteration of my app, with @Darren_Murphy 's help) … to then finally resolve who the winner was, but that took about 2 mins in practice, and I had a loser who wasted time, and a winner who wasted time.
3 Likes
Now who wants to vote for the feature request? 
2 Likes
Vald, it didn’t work. You can see in this attached video that except for item 3, I was able double book every other item. Once for each user. Neither user was aware that the other had booked because the client does not check with the server first to see if any other users have edited the row. It works with the local database copy instead…which may be updated a few seconds later…but not quickly enough to verify if others have touched a row at the same time on their own copy of the database. This allowed for the creation of double bookings that you can see in the Release DATA list. Your method can work so long as users aren’t rapidly booking at the same time, but the way Glide is currently designed with separate databases (google sheet, glide server, and a copy on every user device) there isn’t currently a way to check with the server first before making any changes to data. It always happens locally first, then syncs to the server. Most websites are different from PWA’s because on websites, all or most processing happens server side. On a PWA. however, all or most processing happens on the local device.
2 Likes
I would, but I used all my votes already 
1 Like
Thanks so much for doing the test Jeff. I was just sitting down to try it but it would have taken me quite a bit of work to setup email addresses and to post the video. Awesome.
Thanks for everyone’s comments.
And to anyone in the USA happy Independence Day
2 Likes
You can unvote old items and vote again 
very funny @Jeff_Hager ! lol… i see what you did…
i modified it just for your fast mouse… try it again!
and please make video to show that I beat the Great JEFF ! lol… just kidding.
Happy 4th of July! @Gary_Biagioni @Darren_Murphy @Mark_Turrell @Roldy @Jeff_Hager
1 Like
With my technique, is only up to 5 seconds of wasting time
Round 2. No practice. Just did a straight refresh of both instances of the app after I started recording to get the latest version and run through the list again. Can still get double bookings. This would be much worse if 50, 100, or 1000 people were fighting for the same booking at the same time.
And just for everybody’s information, I’m using a windows laptop with a touch screen, so that’s how I can tap quickly between apps. The left app is in a normal Chrome session. The second app is in an Incognito Chrome session so I can be signed in as a different user. I’m doing this to simulate and record what would happen with two separate users accessing the same parts of the same app at the same time. Again, the effects would be much worse if there were 100’s or 1000’s of users doing the same thing at the same time.
1 Like
Round 3, that seemed better.
1 Like
IMHO you can get him to test a bunch of different scenarios. But really with any time delay between app updates will make it so that you can not obtain a true lock. You may decrease the likely hood of double booking but you can not ever get rid of the ability to double book.
The lock has to be asked for from a source and then returned by that source. Any further requests for a lock have to be rejected by the source until the lock is given up by the requestor or a timeout occurs (if there is a timeout). As long as there is any delay in updates to the apps which we know there is it is impossible to make the lock work.
Imho, Jeff you are wasting your time.
What happens if next week The delay changes to 6 seconds. Does it still work?
why would it change? is me who setting a delay… i set it to 1 sec… and is good… as longer delay that better it is… but 1 sec work perfect
It might be that I a I’m Timbuktu and they have crappy internet. It might be because there was some delay added in a server. It might be that the first requester has a 6 second delay and the the second one has 1 second delay.
If the solution requires a the delay to be less than a certain value it is not reliable.
it dasnt matter… as long is longer than 1 sec
The delay that is important is the delay in updates from the server to the devices.