This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hi Ranchers Which is the correct way in the book() method of client facade class: 1) lock > read and check availability > modify > unlock or 2) read and check availability > lock > read and check availability again > modify > unlock The advantage of the 2nd approach is high performance as you will not wait for lock if required seats are not available for the specified flight Pls suggest Amit
Originally posted by Mark Spritzler: Yes amit two is better, but what you will check in the first check is the value you already have in your JTable, instead of doing two "quick" reads with a lock call in between. Mark
But if i only check the value in JTable, the chances of not getting the required seats is more as the user may have searched for the flight however booked the seat after some time, may be 5 min. If one go for proper read and check before locking thae record, the performnace will be better as if seats are not available why to lock the record. What you say mark ? Amit
Well either way will work. I just used the available seats from the search, because I didn't want to add that one extra network call. I also feel that the chances of the number being off is proportionate to the number of users and the time between searching for flights then booking. My assumption was that the time between searching and booking, and the number of users was low probability. However, when I lock the record, then read it, I check again there to make a last look to make sure the user could book the flight. Again this is a design choice area. Meaning no one answer is right or wrong. Well if you never check to make sure there are enough seats at anytime would be wrong. Mark