• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

NX: Booking method implementation.

 
Ranch Hand
Posts: 319
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
You would be much easier to understand if you took that bucket off of your head. And that goes for the tiny ad too!
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic