Facilities that support distributed transactions on user-defined types can be implemented efficiently and can simplify the construction of reliable distributed programs. To demonstrate these points, this paper describes a prototype transaction facility, called TABS, that supports objects, transparent communication, synchronization, recovery, and transaction management. Various objects that use the facilities of TABS are exemplified and the performance of the system is discussed in detail. The paper concludes that the prototype provides useful facilities, and that it would be feasible to build a high performance implementation based on its ideas. This work was supported by IBM and the Defense Advanced Research Projects Agency, ARPA Order No. 3597, monitored by the Air Force Avionics Laboratory under Contract F33615-81-K-1539, and by graduate fellowships from the National Science Foundation and the Office of Naval Research. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of any of the sponsoring agencies or the US government. Accent is a trademark of Carnegie.Mellon University. Perq is a trademark of Perq Systems Corporation. TAB is a trademark of the Coca-Cola Company. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. © 1985 A C M 0 8 9 7 9 l1 7 4 1 1 2 / 8 5 0 1 2 7 $ 0 0 . 7 5 1. In t roduct ion General purpose facilities that support distributed transactions are feasible to implement and useful in simplifying the construction of reliable distributed applications. To justify this assertion, this paper describes the design, implementation, use, and performance of TABS [Spector et al. 85], a prototype facility that supports transactions on user-defined abstract objects. We attempt to generalize from our experi6nces with the prototype, particularly in the sections on the usage and performance of TABS. We define a distributed transaction facility as a distributed collection of components that supports not only such standard abstractions as processes and inter-process communication, but also the execution of transactions and the implementation of objects on which operations can be performed. Although there is room for diversity in its exact functions, a distributed transaction facility must make it easy to initiate and commit transactions, to call operations on .objects from within transactions, and to implement abstract types that have correct synchronization and recovery properties. Transactions provide three properties that should make them useful in a variety of distributed applications [Lomet 77, Liskov 82, Spector and Schwarz 83]. Synchronization properties, such as serializability, guarantee that concurrent readers and writers of data do not interfere with each other. Failure atomicity simplifies the maintenance of invariants on data by ensuring that updates are not partially done. Permanence provides programmers the luxury of knowing that only catastrophic failures will corrupt or erase previously made updates. Certainly, these properties of transactions are useful in database applications [Gray 78, Date 83]. Database applications are typically characterized by the need for absolute data integrity, permanent updates, and careful synchronization between processes that access large quantities of shared data. When considering the application of transactions to other domains such as the construction of distributed operating systems and real time systems, there are questions pertaining to what transaction facilities should be provided, how they should