Hope it helps!
ps. don't wake up zombie threads. Just start a new thread and ask your question there.
Better would be to just start the whole updating process (including locking) when you have all information needed (so when CSR confirms the booking and has entered the customer id)
Since the rooms are open for booking 24 hours, the best offers will be hunted the most and that could create situation when clients can get angry with too many "this room has been booked by another person" messages. Maybe old system had this problem Unfortunately, instructions don't mention it.
Unless it's breaking any 'must' requirement(s), in my opinion, thin client is the best approach. The reasons being:
1) Locking takes place at server side. Client simply makes a request to server. Server locks the record, makes the changes and unlocks it.
2) Once the request is sent, it doesn't matter if client is crashed. The operation would be performed in a thread-safe manner (i.e. room would be booked as long as no other request for same room is processed).
3) Since server acquires the locks, its far easier to guarantee thread safety. Once a thread obtains a lock on the room, no other thread can obtain a lock (as long as that thread has the lock).
4) With this lock-update-unlock approach, you also minimize the risk of deadlock. No thread locks two records simultaneously, and no record can be locked by two threads simultaneously, so, no deadlock
The only considerable disadvantage is - CSR does actual operation after filling all the information - at which point, it is very much possible that another CSR is locked that room. For this thing, I provided a refresh button - which will simply refresh the status of records.
Anton Kuzmin wrote:clients can get angry with too many "this room has been booked by another person" messages
Well, keeping client happy is not a 'must' requirement(but data integrity is), so I guess its fine if client gets angry
I hope this helps.