5) On the server side the lock, update and unlock methods are called one after the other. Assume user A was 1ms faster/earlier than user B, so his value 11111111 is written in the database file, then after 1ms user B value 22222222 overwrites user A value in the database.
2) Before showing the booking dialog, each user tries to lock the selected record first, assume user A locks the record before user B.
4) The timestamp requested when the dialog was opened is sent to the update method, if the time stamp inside the updated method is the same as the database timestamp then the update method continues as usual, else if the time stamp is different then the update method throws an excption.
I don't have a hotel room scenario rather a contractor book/unbook one. I don't save more than one customer ID for one contractor, my idea was to allow the user to change the booking of a contractor from customer 1 to customer 2. In a hotel room scenario this is not possible of course, but in a contractor/customer scenario this could be legitimate because when contractor X finishes his service for customer 1 then he can directly be assigned to customer 2.
If tomatoes are a fruit, then ketchup must be a jam. Taste this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton