This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Wait, then someone can lock the record for very long time and other clients will be waiting for very long time? And if yes, will they be able to cancel waiting technically? And what happens when client locks and crashes leaving record permanently locked?
It all depends on the approach (thick/thin client) you take. In a thin client approach it's impossible to hold a lock forever, because the locking happens on the server. In a thick/fat client approach it's something that certainly could happen. So you should make a well-thought decision about that part of the application. You should always make sure that the period a record is locked, is as short as possible. If you already lock the record when the user clicks a record to book (and a dialog to enter customer id is shown) you'll risk indeed to lock a record for a very long time (certainly if CSR goes out for a coffee or lunch break) or even forever if the application crashes. 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)
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