Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: concurrent booking requests

 
Dave Knipp
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic