• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

When to call lock?

 
Pallav Grigo
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi..I have a question about the locking architecture..i know that if a client wishes to book a seat(s) on a flight, we must follow the sequence lock>modify>unlock...do i have to follw the same sequence for all modify() operations? in my application i have given the user the permission to modify the flight information..things like the flight timings can be changed...feedback from this forum is always helpful.
Regards,
Pallav.
 
Amund Frislie
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In general, whenever modifying the db file one should follow the sequence mentioned. Why would you give the user permission to change the flight information, apart from 'available seats' (and even this should be changed automatically)?
Cheers,
Amund
 
Branko Paskutini
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pallav, the sequence should be the same. The extra features will be nice POC for your lock code re-usability.
Branko.
 
Pallav Grigo
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have given them permission to modify the flight timings because these things change in real life..a flight could be bumped up an hour or two depending on the flight frequency of the airport..that's why...Yo people are right about the locking though..i should lock and then modify and then unlock...also the seats are updated automatically once the user books a seats..thanks for your replies.
Regards,
Pallav.
 
Tom Doyle
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The project is supposed to implement an end-user interface rather than an administrative interface.
End-users (i.e. travel agents and the general public) would be limited to booking flights. In the real world Delta Airlines wouldn't take kindly to a travel agent changing flight times.
The application could be extended to administrative functions but would then require multiple levels of security authentication and access that would unnecessarily complicate the exercise.
I agree that the lock-modify-lock flow is appropriate. This is similar to the row locks that RDBMS engines such as Oracle and DB2 perform during uncommitted updates.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd add read to that sequence
lock-read-modify-unlock.
Because the first time your ead the file, you get data, but maybe by the time you want to book the flight that available seats has changed. Therefore you need to lock, re-read the flight info, to make sure there are still enough seats, then modify and then unlock.
No administrative features are in the specification.
Mark
 
Pallav Grigo
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello everyone..thanks for your replies..i think you're right about not giving them access to modify..i didn't read the instructions properly..it is for an end user and not for admin purposes...i think i have to remove the capability to add new flights too..coz that would come under admin again..but then why are all these methods made public in the Data class??
Pallav.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pallav. In the original assignment about a year or so ago, it has a requirement of converting a text file into a db.db file. This is the reason why the add and delete methods are there.
Mark
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic