A New Procedure for Ensuring Data Integrity in Flight Reservation
Systems
In the current flight reservation system, a remote operator performs 5-15 transactions to arrange a
flight reservation before finally sending an "end-transaction" message. This final message serves as
a commit message to the server, which then records the transaction to disk and modifies its database.
Before the end-transaction message is sent, the reservation data is held on the system's local disk.
In the event of a system crash, the main processor (or a lower performance backup processor)
reboots and resumes communication with all agents. However, this procedure has no mechanism for
dealing with unfinished transactions, and, consequently, a system crash may produce inconsistent data
between the remote operator's client and the reservation system's server. [the document's problem statement]
The airline currently uses three separate procedures to prevent and address these inconsistencies.
First, it instructs all agents that when a system crash occurs, they should erase the entire transaction
and resubmit it. Second, the airline runs certain consistency check algorithms every night off-line.
These algorithms, however, are simply best-guess estimates and will not identify most unfinished
transactions. Finally, all reservations, including unfinished transactions, are copied onto magnetic
tape. If a customer complains about inconsistency, the airline can check this
record.
