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: Booking method implementation.

 
Jacques Bosch
Ranch Hand
Posts: 319
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys. Have a quick question.
Please give me a few thoughts.
I have used a three-tier approach (I think , with the find and book methods in my DBClient interface implemented in my DBClientImpl class on the server side.
Hence, my locking / unlocking is done only by the book method on the server side.
I have also decided to allow a booking to be over written by a new booking. My book method has a boolean overwrite flag to indicate whether a booking must be overwritten if it is already booked.
But now, on the GUI side, what I have done so far:
When book is clicked, I first try to book without overwriting. If it works, all's fine. But if it returns false, then the contractor is already booked.
So, at this point I retrieve the latest copy of the record from the DB and tell the user who has booked the contractor already, and ask them whether they want to overwrite it.
They choose no. All's fine.
They choose yes, and the book is performed, overwriting anything that was there already.
However, this doesn't seem right to me after I reviewed it, because, the booking call to the DBClientImpl is autonomous. (Lock, book, unlock). So between the time I tell the user that the record is already booked by client x (the rec is not locked for this), and the time the user clicks "yes", it might have been rebooked or modified or whatever by another database client.And hence the info I showed to the user might no longer be valid.
So, should I do it like this? Or should I just let the book be overwritten without even informing the user.
What I did here seems more appropriate for client side locking. I.e. Lock, read latest rec data, book with confirmation, unlock).
Thoughts?
 
Alison Carter
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jacques,
in reply to:
Originally posted by Jacques Bosch:

However, this doesn't seem right to me after I reviewed it, because, the booking call to the DBClientImpl is autonomous. (Lock, book, unlock). So between the time I tell the user that the record is already booked by client x (the rec is not locked for this), and the time the user clicks "yes", it might have been rebooked or modified or whatever by another database client.And hence the info I showed to the user might no longer be valid.

I think you are probably OK. Any user can update information while other users are viewing it. IMO the thing to do priot to an update is check if data has been updated by another user in the meantime. If it has, let the current user decide if he wants to overwrite or cancel (as you have done) -they would be very unlucky for it to happen more than once, but just keep informing the user that there has been an update since their data view was refreshed and let them try again.
Regards,
Alison
 
Jacques Bosch
Ranch Hand
Posts: 319
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, to do that, I would have to do a full hash comparison of the record to check if anything has changed since the last read.
But even then, between the time they are presented with the newest data and the time they click yes, overwrite, the data might have changed and they'll over write the changes without knowing it.
Unless I send my record back to the server in the booking call and do the verification on the server side.
 
Don't get me started about those stupid light bulbs.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic