This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes lock > read > modify > unlock Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "lock > read > modify > unlock" Watch "lock > read > modify > unlock" New topic
Author

lock > read > modify > unlock

Amit Kr Kumar
Ranch Hand

Joined: Feb 08, 2002
Posts: 100
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
Robin Underwood
Ranch Hand

Joined: May 01, 2002
Posts: 117
I'd use option 1 because you don't know for sure that seats are available until you have a lock. Option 2 could lose the seats between the first read and the lock.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

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


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Amit Kr Kumar
Ranch Hand

Joined: Feb 08, 2002
Posts: 100
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
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: lock > read > modify > unlock