Forums Register Login
When to call lock?
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.
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)?
Pallav, the sequence should be the same. The extra features will be nice POC for your lock code re-usability.
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.
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.
I'd add read to that sequence
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.
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. 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.

This thread has been viewed 559 times.

All times above are in ranch (not your local) time.
The current ranch time is
Dec 15, 2018 07:59:19.