Making progress in cooperative transaction models

In the classical transaction model, transactions are consistency preserving units: a transaction is made up of a series of actions which, when executed in isolation in a reliable environment, transforms the database from one consistent state to another [2]. A classical transaction management system guarantees the appearance of isolation and reliability, even though multiple transactions execute concurrently and hardware and software components fail. It does this by enforcing atomicity and serializability: atomicity means that either an entire transaction apparently executes to completion or not at all, while serializability means that the effects of the transactions are viewed as if the transactions had executed in some serial order, one completing before the next begins. This is accomplished by considering the objects read and written by concurrently executing transactions, and ensuring that either all updates are completed or none are, and that the read and write dependencies among the set of transactions correspond to some serial order of the transactions. There have been many proposals for extending the transaction model from its original data processing applications to software development, CAD/CAM and other forms of cooperative work. The notion of ‘‘transaction’ ’ is intuitively appealing in these domains, since forward progress often depends on making a related set of changes to a program, design or document in such a way that it is transformed from one