Hi, ranchers: Here is my understanding and design of lock->read->write->unlock sequence: On my GUI, after a client get the search results, if she wants to book a flight, she has to choose a flight record by clicking on it. Once a record is clicked on, lock() method is invoked. In order to finalize the booking, she will be given instructions to enter the number of seats and press book button (reading process), then modify the record (write), finally unlock. I use lock() in the selection event handling method, and unlock() in booking event handling method. Am I doing right? Any suggestions welcome.
Once a record is clicked on, lock() method is invoked.
What happens when a client clicks on a flight then walks away from his computer? That flight is locked and no one else can modify it. Not good. I had the client select a flight, enter the number of seats desired into a text field, then press a book button. The event handler for the button would do all the necessary validation(ie. make sure a flight is selected in the table, seats not a negative number, etc.) then call a booking method in my Facade. As far as record locking, I had all of that done on the server in my remote implementation of the Data class. I had no record locking performed in my local implementation of Data. You can read alot about this if you search through some old posts about record locking. Some great advice out there especially from Mark and Peter. Mike
Holmes, You want to lock/read/modify/unlock only when the user presses the BookFlight button. This minimizes the amount of time a record will be locked by a client. When you read the available seats, you can validate the value entered by the user.
posted 18 years ago
Thanks, guys for the input, I gonna try out your suggestions. One more thing: if there are two clients online booking the same flight, one has clicked the book button, so she has locked the record, but has not finalized the booking; if another also presses the book button, she cannot book at this time since the record is locked, how do you show this on GUI? Tell the latter the record is locked? (No good) Or just give her a time delay? Thanks. [ June 19, 2002: Message edited by: Holmes Wong ]
posted 18 years ago
You are talking nano second here. Unless the server is down, you should get a quick response. You would know when the server is down and inform the user accordingly.
The time is short, if there is nothing wierd going on with the network. Worrying about the delay I think is reasonable from the standpoint of creating a good GUI implementation... but the record locking isn't the biggest motivation for dealing with delays. Like with any AWT or Swing GUI, you have to be careful of doing work in the event-handling thread when the time required to process the event action could be a problem.