• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

lock > read > modify > unlock

 
Amit Kr Kumar
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Amit Kr Kumar
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic