An Operating Systems Vade Mecum

Transactions 2115 TRANSACTIONSWe have been concentrating on files that are used one at a time by one user at a time.Both of these biases are inappropriate for databases, where single operations mightrequire access to several files, and different users may undertake simultaneous operationsthat need to access the same file. To prevent chaos, we need to ensure that theseindependent operations start with all files in a consistent state and leave them in a consistentstate.The problem is similar to allocating sequentially reusable, non-preemptableresources, discussed in Chapter 4. There are differences, however. We would like toallow several processes to have the same file open for reading as long as none of theprocesses modifies the file. File resources are sharable up to a point, unlike the ones wesaw in Chapter 4. In addition, we may need to refer to several files in order. If anotherprocess changes some of the later files after we have read the first files, we might thinkthat the files are inconsistent.We will use the term transaction to refer to a set of related file accesses, possiblyto a number of files, that one process undertakes in order to perform its work. One processmay be involved in several independent transactions at one time, but this situation isunusual. It is more common for a process to finish one transaction before starting thenext one. Our problem is to make sure that transactions do not interfere with each other.5.1 Synchronization atomicityOur first requirement is that transactions be serializable:SerializabilityThe effect of running a number of transactions concurrently is the same as if they were run in some strict order without concurrency.If there is no concurrency, there can be no interference between transactions. True serializationwould be too conservative (in the language introduced in Chapter 4). Luckily,there are ways of enforcing serializability without requiring serialization. Another wayto describe our requirement is called synchronization atomicity: