An Operating Systems Vade Mecum

Transactions 213a file, and to specify the transaction each time it opens a file. Here are the service callsinvolved:StartTransaction. This call tells the transaction manager that a transaction isstarting. The call returns a transaction number for the process to use.EndTransaction(transaction number). This call tells the transaction managerthat the transaction has finished. It is illegal to end a transaction for which somefiles are still open.Open(file name, intent, transaction number). This call opens the given file andreturns a file number. The ‘‘intent’’ parameter indicates whether the file is to beread, written, or appended. The special transaction number OneShot means thatthe transaction involves only this one file. The special transaction number NoTransactionmeans that the process wishes to violate transaction rules for this file.5.2 Failure atomicityAs we pointed out earlier, transactions are particularly useful for processes that deal withdatabases. During the middle of a transaction, when some file modifications have beenmade but others have not been made yet, the database is likely to be inconsistent. Forexample, transferring funds from one bank account to another might require two separatewrite accesses, one for each account. Synchronization atomicity ensures that no othertransaction will see the two accounts in an inconsistent state, with money deducted fromone but not yet added to the other or added to one without being deducted from the other.However, a hardware or software failure between the two accesses might force the transactionto terminate with the database in such an inconsistent state. Similarly, the transactionmanager may need to abort a transaction that enters a deadlock as it opens a file.(We will see why later when we discuss implementing transactions.) At this time, thedatabase may be inconsistent.Most database management systems require that such inconsistencies be prevented.Failure atomicity is defined as follows:Failure atomicityEach transaction is guaranteed either to completeor to have no effect whatsoever.A failure in the middle of a transaction should either cause all modifications undertakenby the transaction so far to be undone or should preserve the state of the files so that thetransaction will be completed once the failure has been repaired.Most operating systems do not address either synchronization or failure atomicityexcept to forbid simultaneous multiple accesses to the same file. (Unix does not even gothat far.) However, the increasing importance of database management systems is leadingto more sophisticated transaction support within operating systems. Another aspectof transactions, permanence, is a goal of most file managers: Once a transaction