As the TWA flight reservation system stands, a remote operator goes through a series of 5-15 transaction to arrange a flight reservation before finally sending an ``end-transaction'' message. This final message serves as a manual commit message to the server, which then records the transaction to disk and modifies its database. Before the end-transaction message is sent, the flight data is held on the systems 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. There is no mechanism here for dealing with half finished transactions, therefore inconsistencies may arise.
TWA uses a three part system to deal with these inconsistencies. First, they hope that the agent making the reservation will notice that the system crashed half way through and therefore will erase what has been done previously and restart the transaction. Second, TWA runs certain consistency check algorithms every night off-line. These algorithms, however, are simply best-guess. Finally, a hard copy of all reservations is made every night onto magnetic tape. If a customer complains about inconsistency, they can check this record.
Concurrent access to the reservation database is handled through a system of locks. If a portion of the database is to be written on, it is locked for use by the process which intends to modify it. Once that process is finished, it releases the lock. Deadlock is prevented by ordering the locks and requiring that each process take the locks in order.
Using a database like System R would guarantee consistency by periodically logging transaction save points. This would ensure that after a system crash, transactions that were incomplete could be finished without serious interruption. This consistency would prevent the need for additional system complexity such as alert agents, consistency checks and an additional master back up. Although logging with System R decreases performance, it is not terribly significant in this case: about 5%.
In conclusion, a consistent database would reduce complexity by removing all of the consistency hacks that TWA uses, while ensuring that agents still receive acceptable performance.