Isolation-Only Transactions for Mobile ComputingQi Lu & M. SatyanaranyananSchool of Computer ScienceCarnegie Mellon University1. MotivationThe Unix File System(UFS) has historically offered a shared-memory consistency model. The lack ofconcurrency control makes this modelsusceptible to read/write conflicts, i.e., unexpected read/write sharingbetween two different processes. For example, the update of a header file by one user while another user isperforming a long-runningmake can cause inconsistenciesin the compilation results. In practice, read/writeconflicts are rare for two reasons. First, the window of vulnerability is relatively small because read/writeconflicts only occur when the executions of two processes overlap. Second, they are often prevented viaexplicit user-level coordination.However, the advent of mobile computing makes read/write conflicts a realistic threat to data integrity.Mobile computing is characterized by periods of disconnection and intermittent connectivity[11]. Suchcommunication disturbances greatly widen the window of vulnerability from the life span of a processto the duration of a disconnection. They also significantly reduce the effectiveness of explicit user-levelcoordination, especially when disconnections are made transparent to users.How can we preserve upward compatibility with the large body of existing Unix software, while offeringimproved consistency in a mobile computing environment? This position paper puts forth our solution, anew transaction model called isolation only transaction (IOT).2. Background: The Coda File SystemProvidingportablecomputersconvenient access toshareddata in distributedUnixfilesystemsisanimportantresearch topic in the fast growing field of mobile computing. The Coda file system addresses this issueby hiding mobility from applications and users[10]. It provides continuous file access to mobile clientseven when they are disconnected from the servers. The key enabling technology is disconnected operation,a special form of client disk caching which employs optimistic replica control[4]. When disconnected, aCoda client services file access requests by relying solely on the contents of its local cache. Updates areperformed locally, logged and later reintegrated to servers upon reconnection.Coda demonstrated optimistic replication as a viable foundation for mobile clients to access shared files inthe Unix workstation environment. However, data integrity in an optimistically replicated system becomesa serious concern because arbitrary partitioned file accesses are permitted. Two kinds of partitioned datasharing can result in inconsistency. The obvious problem is partitioned write/write sharing because itcauses replicas to diverge. Fortunately, empirical evidence has shown that partitioned write sharing isvery rare in a typical Unix workstation environment[4]. Furthermore, write/write conflicts can be efficientlydetected[9]. Inmanysituations, divergingreplicas canbe automaticallyreconciled usingapplication-specificapproaches[6, 5, 3]. The more subtle threat comes from partitioned read/write sharing.Consider the following scenario of a partitioned read/write conflict. A programmer Joe caches relevant fileson his Coda laptop for a weekend trip. While disconnected, he edits some source files and builds a newversion of repair, a file resolution program. But one of the libraries libresolve.a that is linked inwas updated on the servers during Joe’s absence. Here the linking and the updating of libresolve.aconstitute a partitioned read/write conflict, which not only leaves repair in a possible inconsistent statebut also may cause cascading inconsistencies had Joe used this repair program to mutate other objects.It would be helpful if Joe is at least notified about the possible inconsistency when he reconnects the laptopto the servers.Building upon well-known ideas in the database community, we are extending the Coda file system with anexplicitisolation-only transaction service. Thisenables the system to only admit those partitionedread/writeconflicts that satisfy certain serialization requirements. However, it is important to note that we are nottrying to overhaul the current UFS semantics and replace it with a transactional one. It is simply impracticalto re-write thenumerous existingUnix applications. Instead, we regard upward Unix compatibilityas one ofour key constraints. IOT will be provided as an optional file system facility that application writers can useto selectively wrap-around applications for better consistency protection when used in mobile computing.Existing Unix applications are guaranteed to behave the same if they do not use IOT.3. What is an IOT?An IOT is a flat sequence of file access operations bracketed by beginiot and end iot. The executionof an IOT guarantees a set of properties that are specially tailored for optimistic replication and mobileUnix workstation environment. An IOT provides strong consistency guarantees depending on the systemconnectivity conditions. Unlike traditional transactions, it does not guarantee failure atomicity and onlyconditionally guarantees permanence.The IOT execution model is inspired by Kung and Robinson’s optimistic concurrency control model, witha client’s local cache effectively serving as the private workspace for transaction1processing[7]. When atransaction T is invoked by a user, its entire execution is performed on the user’s client machine. Remotefiles are accessed through the client’s local disk cache; and no partial result of the execution is visible onthe servers. When T’s execution is completed, it enters either the committed or the pending state dependingon the connectivity condition. If T’s execution does not contain any partitioned file access (i.e., the clientmachine maintains a server connection for every file T has accessed), T is committed and its result is madevisible on the servers. Otherwise, T enters the pending state waiting to be validated later. T’s result istemporarily held within the client’s local cache and is visible only to subsequent processes on the sameclient. When the relevant partitions are healed, T is validated according to the consistency criteria to bediscussed in section 5. If the validation succeeds, T’s result will be immediately reintegrated and committedto the servers. Otherwise, T enters the resolution state. When T is automatically or manually resolved,it will commit the new result to the servers. Figure 1