Experience with Transactions in QuickSilverFrank SchmuckJim WyllieIBM Research DivisionAlmaden Research CenterComputer Science DepartmentAbstractAll programs in the QuickSilver distributed system be-have atomically with respect to their updates to perma-nent data. Operating system support for transactionsprovides the framework required to support this, as wellas a mechanism that unifies reclamation of resources af-ter failures or normal process termination. This paperevaluates the use of transactions for these purposes ina general purpose operating system and presents someof the lessons learned from our experience with a com-plete running system based on transactions. Examplesof how transactions are used in QuickSilver and mea-surements of their use demonstrate that the transactionmechanism provides an efficient and powerful means forsolving many of the problems introduced by operatingsystem extensibility and distribution.1 IntroductionQuickSilver is an experimental distributed operatingsystem that was developed at the IBM Almaden Re-search Center for the IBM RT-PC and IBM RISC Sys-tem/6000 families of workstations. It contains a smallkernel that provides local interprocess communication(IPC), process and thread management, and linkagefor installable interrupt handlers. All other system ser-vices are implemented by server processes. Clients com-municate with servers using network-transparent IPC.QuickSilver runs on a network of about 40 machines atAlmaden, and has been used as the primary computingPermission to copy without fee all or part of this material isgranted provided that the copies are not made or distributed fordirect commercial advantage, the ACM copyright notice and thetitle of the publication and its date appear, and notice is giventhat copying is by permission of the Association for ComputingMaohinery. To copy otherwise, or to republish, requires a feeand/or specific permission.@f 99J ACM C).8979J.447+19J 1000910239...$J .SOenvironment for a subset of our local research commu-nity for several years.QuickSilver was designed to make it easy to write so-phisticated distributed programs; the interfaces for ac-cessing files, starting processes, or using any other sys-tem service are the same regardless of whether the ser-vice is local or remote. State associated with such a dis-tributed computation will be split among many serverson different machines. Hence it is vital that the systemprovide a mechanism for servers to take appropriate ac-tions to release resources, recover client state, etc., whenall or parts of a distributed computation end or termi-nate prematurely due to a software problem, interven-tion by the user, or when a machine participating in thecomputation crashes.The distinguishing characteristic of QuickSilver is thatit has borrowed the notion of transactions from thedatabase domain, and extended it to serve as themethod used for all resource management in the sys-tem. In QuickSilver every program runs in the con-text of transactions. The system provides the trans-action management infrastructure for servers that sup-port transactionalatomicity of updates to the state theymaintain. In particular, the QuickSilver file system willundo the effects of all operations performed by a dis-tributed computation if any part of the computationfails before successful completion, i.e., before the trans-action associated with the computation commits.In QuickSilver,transactions are used pervasivelythroughout the system. This made it necessary to ex-tend the traditional notion of a transaction, for exam-ple, to accommodate servers that maintain only volatilestate. In order for QuickSilver to be a complete sys-tem suitable for hosting its own development, it mustof necessity import programs from other systems. Thisimplies that existing programs must be able to run in atransactional environment with little or no modification.The purposes of this paper are to describe both qual-itatively and quantitatively how transactions are used239in QuickSilver and to assess the successes and failuresin our approach of using transactions to unify resourcemanagement in a distributed operating system.The remainder of the paper is organized as follows. Wefirst describe how transaction management is imple-mented in QuickSilver. Next we show examples of howtransactions are used for various purposes in the system,then present measurements of day-to-day transactionusage on our local network. The next section quantifiesthe cost of transactions. We then present lessons drawnfrom our experience with QuickSilver, and closediscussion of related work and our conclusions.2 Transaction ManagementQuick Silverwith ainIn database terminology, a transaction is a collectionof operations that represent a unit of consistency andrecovery. Transactions provide failure atomicity, recov-erability, and isolation [8]. In QuickSilver, transactionsare used to manage volatile resources as well as non-volatile, so these properties are not applicable in thesame way. In QuickSilver a transaction encapsulatesa(possibly distributed) unit of work that maY providefailure atomicity, recoverability, isolation, or any subsetof these.Transaction management in QuickSilver consists of atoolkit that allows clients and servers to choose amongseveral services related to providing the traditionalproperties of transactions. Although the QuickSilversystem enforces that all computation is done in the con-text of some transaction, the exact semantics attachedto a transaction may vary among different servers, de-pending on choices made by the implementer of a ser-vice. The QuickSilver file system, for example, ensuresthat updates made by a transaction are atomic withrespect to failures, and are permanent once the trans-action commits, but it provides a degree of consistencythat falls short of full serializability.The QuickSilver transaction management toolkit con-sists of several pieces:. transactional IPC,● a transaction manager, and● a log manager.We will briefly describe each component of the toolkitin the remainder of this section. An earlier paper [10]LFollowing the terminology introduced by Gray et al. [6],theQuickSilver file system provides degree 2 consistency for file up.dates and degree 1 consistency on directories.presents the overall architecture of transaction manage-ment in QuickSilver and describes the toolkit in moredetail.Transact ional 1P C. IPC in QuickSilver follows therequest-response paradigm. It is similar to