Hi All,
We have an application, where users can book the seats before going to office. Currently application working like - If user A books seat 100 for Date: 20-May-2023 and user B cannot book the same seat 100 for same day Date:20-May-2023 here, if seat 100 is already booked by other user than we are not displaying the seat 100 value in dropdown.
We got one issue in production that, same seat 100 is booked by user A and B for same day 20-May-2023 at the exact time which is observed in process variable. How to handle this to avoid booking same seat for same day?
We are calling process on click of Book button, here in process model activity chaining is enabled before Write to Data store entity. My doubt is whether this activity chaining causing this issue? Please suggest if any solution is available.
Discussion posts and replies are publicly visible
Is the user activity happening within a process, or from like a Site / Record form where you're calling the process asynchronously?
Generally I'd suggest that you DO want chaining, which is usually the only way to guarantee that the refresh behavior following the user activity will cause the user to immediately see the results of the just-run process on-form.
To solve this race condition (i.e. assuming 2 users are about to book the same single-remaining seat within a few seconds of each other), you can add a query in-process just before the WTDS node, to do one last check that the seat is not yet booked, and if it HAS been booked (i.e. user B missed out to user A by 2 seconds), you follow the script task node with an XOR node which routes a different way, writes an error message to a designated PV, quits the process without writing anything, and the interface loads the error message as part of its ONSUCCESS parameter ("sorry, someone has already booked that seat while you were waiting around", etc).
I've tested this sort of setup where 2 people intentionally try to click the action simultaneously, and the process is still fast enough that one of them beats the other to it - so it's suitable for >99.9999% of real-world uses for handling this race condition.
Activity chaining does not cause that issue. The problem is, that two users can book the same slot at the same time when both do it in parallel. You can prevent this from happing by adding a unique constraint to the DB on the fields user and date. Then I suggest to switch to synced records. The write records node allows you to configure whether it halts on an error. Switch this to NO and handle that error yourself.
Unknown said:Activity chaining does not cause that issue.
for real - if anything it's the *solution* to this issue with a bit of creative locking-control, using any of the various methods mentioned.
Thanks Mike SchmittUser activity happening on form like a Site. On selection of Seat number dropdown and Selected Date value BOOK button is enable -> On click of BOOK button starting the process with a!startProcess() and writing to WTDS.As suggested, i will make the changes in process model by putting last check on querying the table and test it. Will post here if any observations found.
Thank you Stefan HelzleCurrently not using Record type in application, initially we will try within existing process by putting check as suggested by Mike. Or else we will try to implement with Record type approach. Will post here if any observations found.