NX: concurrent booking requests

[Dave Knipp]

Hi,
I have the Bodgitt & Scarper contractors assignment and am currently in the design/implementation phase. I came across a possibly problem with multiple users trying to book the same record and was curious how people had dealt with it in the past.
For example, say we have 10 clients who have logged in to the server. They all receive the same 15 records from the database and all have equal rights to choose any of those to book. Say more than 3 clients decide to book the exact same record at the exact same time resulting in 3 requests to the server to book that record. If your locking design is properly implemented only 1 of those clients will be able to lock and book that record. This would result in 2 clients' booking requests being denied.
My question is, how should i implement/react to such a situation?? Its easy enough to know what to do on the server side, b/c you only book the record that got the lock on the record, but what about the client side? Do you report some sort of error when booking to them?? This seems like it would be counterintuitive and make the users pretty frustrated. As a user i would assume that if i was able to click on a record and then click book that it should book that record for me and i would go on my merry way. But in this scenario that i mentioned above 2 users will be denied that functionality.
The last thing i want to do is to send an error message back to the client saying 'That record has been booked' after they had clicked book on that record. Does anyone have any suggestions?? I thought of maybe controlling the state of the book button within the gui depending on record locks on the server, but that seems like alot of work.
If anyone has any ideas that would be greatly appreciated.
Thanks in advance!
Dave
[ October 23, 2003: Message edited by: Dave Knipp ]

[Philippe Maquet]

Hi Dave,

Do you report some sort of error when booking to them??

I simply would report to the user that the record is not available for booking anymore.

This seems like it would be counterintuitive and make the users pretty frustrated.

Yes but it may learn users to work faster.

As a user i would assume that if i was able to click on a record and then click book that it should book that record for me and i would go on my merry way. But in this scenario that i mentioned above 2 users will be denied that functionality.

You're right, but I think that it's acceptable for our assignment.
Best,
Phil.

[Bill Robertson]

Post a message to the users like "The contractor has been booked by another
user". Then refresh and repaint your screen so the user can see that it
has a booking value

[Dave Knipp]

Thats seems like a valid solution, it just seemed odd to me that a user could actually make an attempt to book a record, but then be rejected by the database. There has to be a better way Thanks for your suggestions!
Dave

[Bill Robertson]

One more thing, you might want to throw an exception and let you client or
whoever handles you exception catch the exception and then do what it
wants.
Like: RecordAlreadyBookedException

[Dave Knipp]

Good idea, thats sounds a pretty clean way to show what you expect to happen within the code, especially since we are supposed to cater our code towards junior coders.
Thanks again,
Dave

[Andrew Monkhouse]

Hi Dave,

Originally posted by Dave Knipp:
Thats seems like a valid solution, it just seemed odd to me that a user could actually make an attempt to book a record, but then be rejected by the database. There has to be a better way Thanks for your suggestions!
Dave

Another option is for your client to call lock() at the point where the user selects which record to update. You can then verify that the record is still available and inform the user if it is not. The problem with this is that the user may not be aware that they are holding the lock, and they could go out to lunch - any other client trying to gain a lock on that record would be blocked until the first client returned. This could be partially alleviated if you had an isLocked() method and/or a lockWithinTimeframe() method, but it is still pretty ugly.
Another option is to propogate updates to the client. So when client A updates a record, the server sends the update to clients C, D, E ... This is beyond the requirements of the specification though, and it might get annoying to the clients if there were enough bookings happening - the screen would be continually refreshing.
Hmmm, so many design decisions, and whatever you choose has to be documented
FWIW, having worked in the airline industry for too many years, I can tell you that they work as per the suggestions above - what you see on the see on the search response screen is dated from the moment you get it, and when you attempt to book a seat you can easily get a response back telling you that the seat that you saw as available has already been booked.
Regards, Andrew