This leads me to the better, but way out of scope, solution of writing a virtual database, and locking on it's elements.
when you are in lock() (or the corresponding method of your LockManager), wait() until the record lock becomes available (that is, your lock collection does not contain the record number)
There is an enormous amount of information about locking/unlocking in this forum, and all the answers (including some code) are practically given.
Please search this forum for info on locking. There have been many threads and several different ways to do it.
Let say a we request a lock. At the time of the request, there are 10 records and we are requesting a lock on a record numbered 7. Since there are currently other locks qued up for record number 7, our request waits. While we are waiting, a request that was already in the que acquires the lock it was waiting for, which happened to be for record number 2. This request, however, was for a delete. It deletes record number 2. In due course, we acquire our lock for record number 7 and we execute our request, for ease, lets say it's a simple read. We are now going to be given a read on record 7, but the record we really wanted is now at record 6 - we have just read what we previously thought was record 8
Once you've obtained a lock on a record you must ensure:
1. it has not been deleted by another client
2. the flight number is the one you expected. If not, the record might have been deleted and another flight might have been put in the same position
3. the flight data (e.g. the available seats) fits your needs
Record number 7 is always record number 7, no matter if record number 2 has been deleted. Records don't change their position. This is a valid db:
.. but we can't check to insure the flight is still the same one we expected to be at that position - (at least not server side)..