A New Procedure for Ensuring Data Integrity in Flight Reservation SystemsIn 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.