A New Procedure for Ensuring Data Integrity in Flight ReservationSystems
In the current flight reservation system, a remote operator performs 5-15 transactions to arrange aflight reservation before finally sending an "end-transaction" message. This final message serves asa 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 fordealing with unfinished transactions, and, consequently, a system crash may produce inconsistent databetween 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 transactionand 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 unfinishedtransactions. Finally, all reservations, including unfinished transactions, are copied onto magnetictape. If a customer complains about inconsistency, the airline can check thisrecord.
Copyright ©2001 The McGraw-Hill Companies. Any use is subject to the Terms of Use and Privacy Policy. McGraw-Hill Higher Education is one of the many fine businesses of
The McGraw-Hill Companies, Inc..
