In our discussion of mutual exclusion so far, we have considered atomic access to a single object. What if we wish to atomically access multiple objects. For instance, what if we wish to atomically remove an item from the input buffer and put it in the echo buffer? The high-level constructs such as monitors and path expressions do not give users of shared objects flexibility in defining the unit of atomicity. They expect the programmers of shared objects to define the unit of atomicity. But the programmers do not know which other objects may be accessed concurrently (by object users) with the objects they are programming. Low-level mechanisms such as semaphores are not bound to a particular object, and thus can be used to provide multi-object atomicity. But these are hard to use and special care must be taken to ensure deadlocks are prevented.
Thus, what is needed is a higher-level abstraction for ensuring atomic access of multiples shared objects. The transaction is such an abstraction.
Trsnsaction models have been developed in the context of database management systems, operating systems, CAD tools, collaborative software engineering, and collaboration systems. We will focus here on the operating system models and the classical database models on which they are based.
Trsnsactions do not address both aspects of process coordination - they addresses mutual exclusion but not synchronization. However, in the context of transactions, ensuring mutual exclusion is called synchronization, which should not be confused with the producer-consumer synchronization we have seen so far.