Concurrency Control in Groupware Systems C.A. Ellis S.J. Gibbs MCC, Austin, Texas Abstract. Groupware systems are computer-based systems an hour or two in length but may be much shorter or much that support two or more users engaged in a common task, longer. At any point in time, a session consists of a group of and that provide an interface to a shared environment. These users called the participants. The session provides each par- systems frequently require fine-granularity sharing of data ticipant with an interface to a shared context, for instance and fast response times. This paper distinguishes real-time participants may see synchronized views of evolving data. groupware systems from other multi-user systems and dis- The system’s responsetime is the time necessary for the ac- cusses their concurrency control requirements. An algorithm tions of one user to be reflected by their own interface; the for concurrency control in real-time groupware systems is notification time is the time necessary for one user’s actions to then presented. The advantages of this algorithm are its sim- be propagated to the remaining users’ interfaces. plicity of use and its responsiveness: users can operate di- Real-time groupware systems are characterized by the fol- rectly on the data without obtaining locks. The algorithm lowing: must know some semantics of the operations. However the algorithm’s overall structure is independent of the semantic * highly interactive - response times must be short. information, allowing the algorithm to be adapted to many * real-time - notification times must be comparable to situations. An example application of the algorithm to group response times. text editing is given, along with a sketch of its proof of cor- * distributed - in general, one cannot assume that the rectness in this particular case. We note that the behavior participants are all connected to the same machine or desired in many of these systems is non-serializable. even to the same local area network. * volatile - participants are free to come and go during 1. Introduction a session. Real-time groupware systems are multi-user systems where *ad hoc - generally the participants are not following the actions of one user must quickly be propagated to the a pre-planned script, it is not possible to tell a priori other users. An example that many find easy to relate to is what information will be accessed. the multi-player game. Here the movement of one player’s *focused - during a session there is high degree of token, perhaps a tank or spaceship, triggers updates on the access conflict as participants work on and modify the displays of all players. Other examples can be found in the same data. area of computer-supported cooperative work [CSCW86, *external channel - often participants are connected CSCW88]. For instance, in real-time computer conferencing by an external (to the computer system) channel such [Sari&j], the users, who are often at different locations, com- as an audio or video link. municate through a software medium. This software might allow the users to view and modify a shared graph structure It is useful to distinguish groupware systems from other [Stef87] or edit a shared outline [Elli88a]. Our research multi-user systems. For example, both database manage- group has been studying, and experimenting with these types ment systems and timesharing operating systems support of systems for several years. We now recognize that there multiple users. However neither of these are groupware since are significant challenges in implementing these systems that they provide little notification - if one user performs some typically do not arise in other applications. Some of these action, perhaps inserting a tuple or creating a process, other challenges [Elli88b] reside in the areas of group interfaces, users are not normally notified of the action and may only access control, social protocols, and coordination of group learn of it by explicitly querying the system. operations. For instance, groupware introduces new com- One example of groupware is GROVE (GROUPOutline View- plexities to the user interface: the interface must depict ing Editor) [Elli88a], an outline editor which we imple- group activity, and designers must weigh the need for group mented in the Software Technology Program at MCC. It is focus against the potential for distraction. Concurrency con- intended for use by a group of people simultaneously work- trol also has novel aspects within groupware as we will dem- ing on a textual outline. GROVE supports multiple views of onstrate in this paper. the outline, each view is displayed in a group window (a win- An invocation of a groupware system is informally called a dow replicated over a set of machines). A window may be session. Sessions in which we have participated are typically private, shared, or public. A GROVE group window is shown in Figure 1. Participants can modify the underlying outline by performing standard editing operations (insert, delete, cut, paste, etc.) in the window, they may also open and close Permission to copy without fee all or part of this material is granted provided that parts of the outline (using the small buttons on the left side) the copies are not made or distributed for direct commercial advantage, the ACM or change the read and write permissions of outline items. In copyright notice and the title of the publication and its date appear, and notice is addition to displaying views, group windows also indicate given that copying is by pemksmn of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific pemkion. who is using the window. The window in Figure 1 will appear 0 1989 ACMO-89791~317-S/89/0005/0399 $1.50 on the workstations of the three users shown along the bot- 399 addition to displaying views, group windows also indicate cations do not appear to be suitable in this context. In the who is using the window. The window in Figure 1 will appear following we identify some of the issues related to concur- on the workstations of the three users shown along the bot- rency control in groupware systems and then discuss the tom border. An important characteristic of this system is that drawbacks of current approaches. edits performed by any participant are rather immediately seen on the screens of all participants (real-time notifica- tion). view id 1. Item l is readable and writable. 1.1 Item 1.1 is also readable and writable. *. This private item is readable and writable. *.* This private item is read-only. rtgure 1 bmuvt group wmaow A very closely related class of groupware systems is what 2.1 Issues might be called non-real-time groupware. Examples are edi- wyS1WIS. Although there has been little experience in the tors such as CES [Grie86], Quilt [CoheBB], or Shared Books evaluation of interfaces to groupware systems [GrudBB, [LewiBB]. These editors allow a group of users to work on E]]i89] it appears that some form of a WYSIWfS (what you the same document, however each user typically works on see is what I see) interface [Stef87] is necessary to maintain their own section at their own pace. As a result sessions are less focused and are longer in duration (days or even weeks group focus. If each user sees a slightly different or out-of- in length); also real-time notification may not be necessary date version then the session’s cohesiveness is soon lost. because of the asynchronous nature of participants’ actions. WYSIWIS interfaces have two implications on concurrency Given these distinctions, the remainder of this paper will control. First response times are important - the time taken concentrate upon real-time groupware, although we will sim- to access data, modify data, or notify users of changes must ply use the term “groupware systems.” be as short as possible. Secondly, if the concurrency control scheme entails the use of modes where actions of one user In this paper we present an algorithm for concurrency control are not immediately seen by the others, then the effect of in groupware systems. The next section explores issues re- these modes on the group’s dynamics must be considered lated to concurrency control in this context and describes and only allowed if they are not disruptive. problems with alternative approaches. In Section 3 we pro- vide a model for groupware systems. The algorithm is devel- Wide-area Distribution. One of the main benefits of group- oped in Section 4 and applied to GROVE in Section 5. Dis- ware systems is that they allow people to work together, in cussion of its correctness is presented in Section 6. real-time, even though separated by great physical distances. Consequently these systems may be geographically distrib- uted. With current communications technology, transmission 2. Concurrency Control Problem times and rates for wide-area networks are significantly Concurrency control is needed within groupware systems to worse than those found in their local area counterparts, the help resolve conflicts between participants, and to allow possible impact on response time musr be taken into ac- them to perform tightly coupled group activities. For exam- count. ple, with a group editor such as GROVE, clearly there is a Replication. Because the response time demands of group- conflict if one participant deletes a sentence while a second ware systems are so high, the data state is usually replicated inserts a word into the sentence. The various approaches to for each participant. This allows many potentially expensive resolving these situations, such as explicit locking or transac- operations to be done locally. For instance, consider an edit- tion processing, that have been developed for database appli- ing session where one participant is in Los Angles and the 400 other Austin.