Notes on Concurrency Control in Groupware

Tim Kindberg, January 1996

1. Introduction
These brief notes explore the requirements and design issues surrounding concurrency control in groupware software with which several users, often geographically separated, collaborate on a shared task such as document writing. The next section gives an overview of groupware. We then give requirements and design issues, and go on to discuss how traditional concurrency control techniques such as database transactions are usually inappropriate for groupware, and describe and discuss alternatives. Finally, we suggest some categorisations of the ways in which users receive information about shared objects and the ways in which they interact in shared tasks.

2. Groupware
A groupware application manages a shared collection of information objects and communication channels through which users interact. The purpose may be collaboration on a common set of tasks, or it may be for wider forms of social interaction. In a synchronous application users interact at the same real time. Users interact using a synchronous groupware application in sessions . A session is an invocation of the application by one or more collaborating users: it begins when the first user invokes the application and ends when the last user leaves. In an asynchronous application users may be present at non-overlapping times: they use a shared medium such as email or a bulletin board to coordinate their activities. An application may allow both types of interaction. We make the following observations about the components found in groupware applications. In referring to software actions we shall sometimes speak of the application, and sometimes the system. Shared objects. These include the task-related objects that the users examine, update or interact with; they include for example documents, whiteboards and representations of entities in a shared virtual environment. Although users are said to share a collection of objects, there may be differences between the ways that the application presents the same objects to different users, and different interactive capabilities may apply: you and I use different colours or fonts for the same document; we see the cursor at different locations in the text; my screen differs from yours: we are viewing different parts of documents, and the windows are in different locations on the screen; I may not update the document, but you may; the editing interfaces we use differ correspondingly. We refer to underlying shared objects such as document sections as the target objects (see Figure 1). A target object contains state that the users agree on. The state belongs to an entity that is either part of the application data, such as the text of a document section; or part of the collaboration, such as a user. But the groupware user only really sees and interacts with what we shall call view objects: windows and other interface components through which users observe and/or update target objects. We say that a view object presents a target object or part of a target object to a user (some view objects, such as scrollable windows, only present part of a target object to the user). We have described ways in which view objects presenting the same target object differ between users; but they may in some cases be guaranteed to be the same. The mapping of target objects to view Version of 7/1/96

objects for the same user may be one-to-many (for example I may use several windows for the same document). We follow Bentley et al [1992] in defining a selection to be the set of (parts of) target objects currently presented to the user; a composition is an arrangement of views on the users screen. Users do not normally have to agree on either the selection or composition.

User 1

View objects

User 2

Target objects
Figure 1. Target objects and view objects. Communication channels. Communication is necessary for coordinating interaction. Users may communicate using audio, video, text or by gesturing using shared objects. The whole group of collaborators or a subgroup may talk to and hear one another; they may also be able to see live video of or gestures made by one another. In the most limited case, they may communicate only textually. Communication may be synchronous or asynchronous. We define direct communication to be information-imparting actions made to be observed by particular users. By contrast, acts of indirect communication impart information, but not to a particular user. Events . Users (at a lower level, processes acting on their behalf) may receive notifications of events: event descriptions, sent asynchronously. This is a form of indirect communication. All those who have registered interest are notified, for example, that a change has taken place or may take place to a named object but they are not necessarily informed at that point of what the change consists of. Names. Collaborating and interacting with shared objects normally implies sharing a name space also. Users need to use unambiguous names when communicating with one another; they also need to use unambiguous names when invoking commands through the computer system. Consider Jims request Mary, have a look at calc.cc. Here, Jim and Mary use a name calc.cc in their audio communication, which is the same name that the shared filing system resolves to the required object. In order that users can collaborate, in general, we require that target objects have global names, which are known to the system as well as users and which are unique in the application context. Now consider the following examples: Jim, have a look at the spreadsheet The one you want is third down in the directory. The blue folder The paragraph that ends in Beetlejuice This one (Jim points with the mouse to something on his screen). These examples show that the existence of separate views, selections and compositions may make some convenient, everyday naming conventions problematic. Names that are dependent on configurable presentation parameters (colour, position etc.) arent any use unless we share a configuration. Names that are formulated as characteristics may not be

any use if the object concerned is allowed to be (temporarily) inconsistent (there is no paragraph ending in Beetlejuice: Jim typed that in and Mary has not seen it yet). However, in principle at least, the application may translate to some extent if users point at objects, as Jim does in the final example. It can do this either by propagating a global name for the referenced object or by pointing at the corresponding view on Marys screen. Users. Awareness of one anothers activities is often important for collaboration [Dourish & Bellotti 1992], and it is normal for collaborating users to be presented as shared objects. Simple examples are: we may see 3D graphical images of one another in a virtual environment; we see graphics or videos of one another on the screen. However, userrepresentations can have more information and interactive capacity than mere recognizable icons or video images: user-representations may carry persistent personal data (email address etc.) they may carry data about the users current activity. For example, by clicking on the users icon I see the views that they see currently. The user may also have a recognised role, giving him/her recognized rights and allowing others to have expectations of what the user will do. For example, I see that the user is chair of the teleconference, or that s/he has the floor and is addressing the conference. Finally, a user who is not currently engaged in the collaboration may leave a representative object that can answer simple questions about the users progress. Activities . A collaboration may involve several tasks (for example, brainstorming, writing a first draft and editing a document). Collaborators carry out some tasks concurrently, working autonomously or in subgroups. Some tasks depend upon the completion of other tasks. It is necessary to agree the set of tasks to be carried out, and to manage their consistency (tasks must make sense together) and synchronisation. An obvious representation is a workflow management object. However, this may be of little use where collaborations do not have a structure that is known in advance. For such dynamic collaborations, it is not clear how to monitor or represent the current activity of a given user. Workspaces. A workspace (c.f. locale, room, shared desktop) is a context and unit of resource management for collaboration and interaction. It contains shared objects and tools, communication channels and representations of the users interacting with them. It supports awareness and communication between users within the workspace, and filters out unwanted communication originating beyond the workspace. It may be a unit of security access to the workspaces contents may be restricted. It may also be a unit of consistency management for shared objects of which the collaborators maintain several versions [Kindberg 1996].

3. Consistency and concurrency control requirements

3.1 Motivation Concurrency control is needed in groupware to maintain shared objects in a consistent state, despite concurrent updates from several users. Informally, consistency concerns agreement between objects, defined according to constraints that take the applications semantics into account. The main questions regarding consistency are: Does the collection of objects currently presented to an individual user obey application constraints? Do the views of the same target objects presented to several users agree sufficiently to allow them to interact and collaborate?

To help answer these questions, we can break inconsistency down into three types: View inconsistency. This is where two users views of the same part of the same target object differ. We noted above that different users view objects do not need to agree in all respects. For example, a documents text and key aspects of its format must be the same for all users in the final stages of editing; but the colours used to present a black-and-white document to the user are a matter of personal choice. We shall not consider view inconsistency further. Communication asynchronicity. Delays in network communication and asynchronous operation may lead to inconsistency between the content of user communication and views. For example, if Mary comments on a video of a race that the application displays to all users, then she may be heard to announce the winner before or after Jim sees the race end. Similarly, Mary may send an email message referring to a state of affairs that no longer obtains when Jim reads it. Target object inconsistency. We shall have little to say about view inconsistency and communication asynchronicity in this paper. Our focus is on target object inconsistency. First, it is possible for users to damage the integrity of the collection of target objects by making concurrent updates. Second, although we may consider that different users view one collection of target objects, in reality they sometimes view different versions of the same conceptual object. There are several factors that mitigate against users being able to access a consistent set of target objects: Conflicting updates. Two or more users may each attempt to make a series of updates concurrently which conflict with one another: if the updates were allowed to proceed without restraint they would leave the shared objects in a state that breaks the constraints of the application. This is a well-known problem in the database world, and the transaction mechanism exists to solve the problem in that world. Operation latency. Users experience varying latencies when accessing data over a network. In general users cannot access exactly the same data at the same real time. Disconnection. A network partition may disconnect a user or subgroup of users from the rest. Or a user may deliberately disconnect her mobile computer from the network. If these users continue working, their copies of target objects may diverge. Replication. Often shared data are replicated for efficient access and reliability. Each users workstation or each of several server machines (or both) holds a copy, so that users are close to at least one copy of the data. Because of variable communication latencies and variable message arrival order, the copies of the data may diverge. The degree of agreement implied by consistency depends upon the application. For example, in the USENET newsgroup system, users observing the latest postings to a given newsgroup at the same real time will not necessarily see the same set of postings or the same ordering. It may also be argued that the postings displayed to an individual user are sometimes inconsistent, for the user can see a posting whose subject is re: Bill Gates is a Monster, without having read the original message with subject Bill Gates is a Monster. But this application is useful despite these inconsistencies. As another example consider two surgeons in the same virtual environment, one of whom is teaching the other how to perform an operation. Here we require that certain objects and their relationships in the virtual environment look the same to the two users. In particular, the positions of bodily parts and instruments should be as exactly matched between the users as possible. But there may be other factors such as the time shown on a clock on the wall, that need not exactly match.

3.2 Requirements Now that we have motivated the need for concurrency control in groupware and considered the different types of inconsistency that can arise, we consider our requirements of a concurrency control function. These are in no particular order. Cooperation. The concurrency control mechanisms should not interfere with users need to cooperate with one another for example, to demonstrate updates to one another. Dynamic set of users. Concurrency control must be correctly applied even though the set of users involved in a session varies over time. Users joining a groupware session should be given a view of the applications state that is consistent with the current views of other users in the session. Failure. Adequate protection must be provided against inconsistencies due to failure during updates. Support vs constraint. In some applications it is appropriate that the system should enforce consistency. In others it is appropriate for the system to help users avoid conflicts, but to leave it to the users if they want to risk making inconsistent changes. Low latencies. For the groupware application to be usable the time lags between making a user-interface action (e.g. clicking on a button) and seeing the results on the screen must be kept below the threshold where they slow down and irritate the user. Object- or class-specific control. Consistency requirements vary between objects or types (classes) of objects, so concurrency control must be selective. For example, it may not matter if two views of a shared whiteboard differ by a pixel or two; but it may be crucial that two views of the same part of a shared document do not differ textually at all. Resolution rather than abortion. Where optimistic techniques are used, the concurrency control system should give users the option of resolving conflicts, rather than aborting work. This is particularly true of long-lived transactions , which are common in groupware. For example, a programmer may update source code files over several days. The concurrency control system should not discard such a large effort because of a conflict with other changes. The system should assist in avoiding the conflict in the first place. Also, if updates may conflict with other updates, then the user must know this at the time. Undo . The net effect of changes that several users make concurrently can be hard to predict; it is essential that users should be able to recover previously agreed versions of shared objects. Dynamic transactions. Users may make unpredictable sets of changes to shared objects. The concurrency control function cannot rely on prior analysis of transactions.

4. Concurrency control options

4.1 Replication There are several system architectures for groupware: centralised (a central server holds target objects) replicated (target objects are replicated at all user workstations) hybrid (there may be several servers, and data is replicated) disconnected (mobile computers). In a centralised architecture without any replication the shared objects are all stored and updated at the server. Users at workstations run a windowing system, which is used to accept updates destined for the server from the user, and to which the server propagates display information.

The server in a centralised system acts as a bottleneck and a critical point of failure. Some replication is normally required in groupware, at least replication of objects to which workstations need frequent access. Hybrid systems may replicate objects between several servers as well as between workstations. Dourish [1995a] points out that different architectural approaches may be suitable at different times for the same target object. For example, a system uses a central server when just two users share a document on a single Ethernet segment; but it uses a replicated approach when another, distant, user joins. Where modifiable objects are replicated, the issue arises of how to keep the replicas consistent. We can maintain the consistency of copies of an individual target object in real time by using ordered multicasts: in the centralised architecture the server orders and multicasts all updates; in the replicated architecture the updates are delivered using a logically decentralised multicast (although a sequencer process may be used to obtain total ordering). Various orderings may be appropriate for individual target objects: FIFO, causal, total, total-and-causal and cautal [Kindberg 1995]. Multicast mechanisms are widely used in distributed virtual environments, for shared whiteboards, for text editing, for event notifications and for audio and video conferencing. Object groups [Achmatowicz and Kindberg 1995] are a structuring mechanism for managing the consistency of replicas of individual target objects. Unordered multicasts, which are cheaper, are sometimes used. The argument for this is that operations on target objects often commute. Several groups have suggested a means of recovery when a system performs non-commutative operations in the wrong order at a site. If F and G are such operations, then the programmer has to supply H and H' such that H(F(G(state))) ~ H' (G(F(state))). This presupposes that the system is able to decide which is the right order for the operations and detect inconsistencies. It places a great load on the programmer, who has to supply H and H' for potentially many combinations (F, G). It is confusing for the user to see operations being transformed by the system: the result might not be recognisable as anything any user intended. Note that the question of how to resolve two inconsistently ordered operations is similar to that of how to undo an operation in any interactive system. The difference here is that no user requested this undo operation: it is an artifact of the systems concurrency control mechanism. During disconnected operation we have no choice but to log updates and merge and reconcile them at connection time. We may implement this as a persistent multicast [Maffeis 1994], whereby updates are logically multicast under disconnected operation, but they are stored until reconnection takes place. The multicast-based mechanisms that we have described are not sufficient to apply several changes that must atomically update one or more target objects. For example, consider a change to source code that involves updating a procedure and all the code that calls the procedure (the signature is changed). Traditionally, transactions have addressed this general issue. 4.2 Transactions Conventional transactions were designed for concurrently accessed general-purpose databases. They provide the ACID properties: atomicity, consistency, isolation and durability. They are based on locking (pessimistic) or optimistic techniques. We now examine the ACID properties in the context of groupware requirements. Atomicity. Atomicity refers to performing either all of a sequence of operations to one or more objects or none of the operations at all in order to preserve the consistency of the

collection of objects. This is often a requirement in groupware. But there are cases where there is no natural unit of atomicity. For example, if Mary and Jim cooperate in the design of a complex artefact, then the design or an alteration to the design is complete only when they decide that this is so. Consider a document section which Mary cuts and stores, with the intention of placing elsewhere in the document. We would not want the system to insist that Mary places the section back in the document, because it has become inconsistent. In fact, Mary and Jim may later decide that the section is redundant. Consistency . The consistency of a collection of objects may be broken by the interleaving of two sequences of operations, even if each sequence is performed atomically. Conventional transaction systems maintain consistency by enforcing read-write serialisability the effect of several transactions is made equivalent to their execution in some serial order. We know how to build systems that enforce this definition of consistency automatically. However, shared access to objects in groupware is liable to be cooperative and therefore unserialisable (users take actions based upon others partial results). Forcing serialisable schedules is liable to impair cooperation, because of locktaking or transaction abortion. Serialisability is expensive to implement and is often too strict compared to the applications consistency constraints. A serialisable schedule of updates leaves the database consistent; but a non-serialisable schedule may also leave the database consistent. Serialisability is For example, a software development supervisor may perform a read-only transaction to gain a snapshot of the development process, which ignores updates being carried out concurrently. The resultant data is not strictly consistent, but is good enough. Serialisability is also too strict because, for example, a transaction may read a value that it never uses: a transactional system will insist on serialisation with a transaction that wrote that value, even though it may be unnecessary in this case. The strictness of serialisability is a well-known problem; unfortunately, attempts to solve it by defining an application-specific notion of consistency are cumbersome to program. Using semantic consistency we allow schedules that are not serialisable (i.e. as measured by read-write ordering), but nonetheless preserve application consistency. We may also distinguish between serious and nonserious conflicts. Unfortunately, a DBMS at the heart of an application cannot tell whether each possible schedule of interleaved operations preserves application-specific consistency; it may be able to check the resultant state against constraint predicates, to see if it is consistent. Dourish [1995b] distinguishes syntactic consistency from semantic consistency. This ensures that the shared objects retain structural integrity, although semantic consistency may be broken. For example, if two users edit the same paragraph then an intermediate resolution of this is to place both edited versions side-by-side in the document. Isolation. Sometimes isolation is valuable in groupware. For example, other users may not want to see the individual updates I make to a paragraph in a shared document: they only need to see the completed result. However, there are many other situations (collaborative design of artefacts, shared virtual environments, brainstorming) where individual updates must take effect at once everywhere. A development of transactions from the database world that may be applicable in groupware to relieve the problem of isolation is dynamic restructuring of transactions. Splitting a transaction means dividing up a single transactions resources and allowing it to fork into two transactions, which proceed concurrently. This is acceptable as long as the result leads to consistent results. One of the main uses for splitting a transaction is so that one may commit early, allowing another transaction to access its resources. Suppose Mary is in the middle of updating several objects, and john needs one of them. If Mary has finished with this object, and if what she has done involving it is globally consistent, regardless of whether whatever else she goes on to do commits, then she may commit the

part of the transaction that has updated the object, allowing John to access the data while she proceeds concurrently. Similarly, we can consider joining two transactions: holding on to resources which we were going to commit and follow with a different transaction, but which we have now discovered we still need. Durability . It is often a requirement in groupware that target objects should persist beyond the execution of the programs that made them. Summary In summary, it would seem that the only general requirements for groupware transactions are the CD properties: consistency interpreted relative to the application and not necessarily equated to serialisability and durability. Atomicity is not always relevant to free-form group interactions, and isolation is often disadvantageous. 4.3 Concurrency control mechanisms for groupware This section gives an overview of techniques to support relaxed forms of concurrency control suitable for groupware. The two techniques available from the database world are locking and optimistic concurrency control. Conventional locking has several disadvantages for groupware. First, each requested transaction on the shared objects is blocked while it obtains the necessary locks. But locks that are taken for humanly perceptible periods of time can be very obstructive to group working. Second, a particularly difficult problem to solve satisfactorily is that of choosing the right granularity for a lock. If a lock governs too much data, then the chances of conflict for the lock are high but there is relatively little locking overhead per object-access; conversely, reducing the amount of data governed by each lock may reduce contention but it increases the locking overheads. A third disadvantage of locking is that in groupware it is hard for the system to ascertain when a lock should be taken or released. In an editor, for example, should the system request a lock when the users cursor enters a paragraph, or when she types a key? Should the lock be released when the cursor moves out of the paragraph? Finally, locks require total communication connectivity to function correctly and so are not suited to disconnected operation. This is so whether disconnection occurs deliberately (mobile computing) or through failure. In optimistic concurrency control, a transaction updates logically separate versions of shared objects, and then attempts to merge back the new versions of objects. If the system detects no conflict then re-integration goes ahead. Otherwise it aborts the transaction. Optimistic concurrency control allows users to proceed without the overhead of obtaining locks. Another advantage over locking is that it allows users to make progress under disconnected operation. But conventional optimistic concurrency control also has disadvantages for groupware. First, if a transaction aborts then all its updates are lost. But as we pointed out above it is usually unacceptable to throw away the users work. Furthermore, conventional optimistic systems provide no mechanisms for keeping the user sufficiently well informed to be able to avoid conflicts where this is possible. We now examine alternatives that overcome some of the disadvantages of locks and optimistic concurrency control. Social protocols. Some synchronous applications such as audio or video conferencing employ locks to enforce turn-taking (floor control). But this sort of concurrency control is often left to social protocols: the interacting users observe an informal protocol to avoid interrupting one another. Another example is where users draw on a whiteboard concurrently: users communicate and yield to one another when they realise that their drawing is conflicting. Social protocols are sometimes supported at the user level by the notion of roles. For example, the chairperson of a conference has the power to control concurrent activities to control who can take the floor. (Such power is not always

merely conventional; in other designs the system constrains users to behave according to their current role [Leland et al 1988].) The problem with social protocols is that they offer no guarantees and therefore cannot be replied upon in many applications. A disadvantage of roles is that they are often too restrictive it is awkward to change roles as a collaboration progresses and requirements change. Locks with notification. There are two types of locks with notification. In the first, locks have conventional locking semantics, but the system notifies users of operations that would block because a lock has been taken, so that they may avoid these operations if possible. In another approach, called notify locks [Skarra et al 1986], a process informs the system when it is about to read an object by taking a notify lock. The reader is never blocked by such a lock, but the system sends a notification to the process if the object changes. Again, these techniques have only a restricted application in groupware. Weak locks. These are locks that have weaker semantics than conventional locks, and which are integrated in groupware in an effort to assist users in making progress where transactions are long-lived. Tickle locks [Grief et al 1986] may be broken if the user who holds them becomes inactive. For example, if I dont edit a shared document for a time greater than a threshold value, another process may take the lock away. Optimistic locks [Greenberg 1993] are an attempt to avoid the high latency of lock acquisition. The system initially assumes that it will be successful in acquiring the optimistic lock, and allows updates as though the lock is held. When it manages to access the lock, the system either confirms that the lock is now held or it notifies the user that she has potentially updated a locked object. The user is invited to integrate her updates. In semi-optimistic locking the system only allows the user to have at most one optimistic lock at any time, to reduce the complexity of integration. Using probabilistic locks [Greif and Sarin 1988], if a process cannot obtain all the locks it strictly requires within a given time the system allows it to proceed anyway if it (or the user) so decides. Tickle locks, optimistic locks and probabilistic locks are acceptable only in an application that supports integration of potentially conflicting updates. Such applications grant a reasonable probability of successfully completing an operation, not a guarantee. It is misleading to call these synchronisation objects locks at all. They are all an ill-defined way of approaching concurrency control through optimistic techniques, where the real problem faced is that of integrating conflicting updates. Even the guarantee of a confirmed optimistic lock hardly offsets the problem of dealing with edits made when the lock turns out to be held elsewhere. Optimistic concurrency control with notification . In optimistic concurrency control, notifications may assist in avoiding conflicting updates. At the lowest level, users are informed when an object has been checked out for updating. Notifications are also useful where objects depend upon one another. For example, an index entry depends on the position of the corresponding document text, and the software or user managing the index needs a notification when the corresponding text moves. A more sophisticated scheme models dependencies, rather than relying on the user to declare dependencies in an ad hoc way. Narayanaswamy and Goldman [1992] describe a design in which intended changes are announced before they are made, so that potential conflicts can be analysed before they occur. Yet another enhancement is for the system to open a communication channel between users making potentially conflicting updates [Ege and Ellis 1987]. Conflict resolution. Despite attempts to avoid them, conflicting updates may of course occur under optimistic concurrency control. The system can offer the users a chance to resolve conflicting updates. However, it is sometimes possible to resolve conflicts automatically in an application-specific way. For example, in the Bayou database system

for mobile computers [Terry et al 1995], update operations include merge procedures, which integrate the update with the database in a way that takes into account conflicting operations, according to the application semantics. Providing merge procedures to resolve all possible conflicts can be a very tall order for the programmer. Guarantees. Dourish [1995b] defines the notion of a guarantee of achievable consistency as an alternative to locking. The system assures a degree of consistency, as long as all the clients obey promises. For example, I may read any objects without locking, as long as I promise not to write any data. To support opportunistic working styles, a client may break its promise, but the system then dissolves its guarantee. After obtaining a guarantee and providing a promise, a client produces a stream of operations (invocations, their parameters and contexts). The system warns the user when she is breaking a promise and conflict may occur. Then there is a synchronisation point. Attention is paid to whether clients have broken their promises. If one has, the system enters a conflict-resolution phase. An action that conflicts with another action, for which no guarantee was provided, is merged to give structural consistency (see above). However, if an action conflicts with a guarantee then a more sophisticated approach is necessary. There may be no actual conflict. For example, I may make a series of updates even though I promised not to, but the system accepts them because no other user made any updates at the same time. The system guarantees to integrate updates made by clients who have kept their promises, but it may still be possible to integrate updates made with broken promises. Summary In summary, this section argues that: target objects often need to be replicated for responsiveness and robustness locks impair interactive responsiveness there are several techniques that avoid the disadvantages of locks but which are only useful in a limited class of groupware approaches to weakening locks are little different from optimistic concurrency control techniques optimistic techniques seem more promising than locks for allowing progress, but they require support for mutual awareness to avoid conflict and for conflict resolution it is unclear how successful automatic approaches to conflict resolution can be, because of the complexity of dealing with all possible conflicts it seems most useful to provide assistance to users by warning of possible conflicts and providing version management tools, which they may use in detecting and resolving conflicts.

5. Classifying interactions in groupware

We now use our knowledge of concurrency control issues to expand upon Section 2s general model of a groupware system, which stores and presents an evolving collection of shared target objects. First we recall that there are three ways in which a user may be informed about a shared object, which we shall call object-information modes: direct communication (e.g. person-to-person audio) indirect communication in particular, event notifications observation the user sees the target object through a view object.

10

A user may be informed about an individual object by any combination of objectinformation modes. For example, Jim may tell Mary about the introduction to a document while she views the conclusions. We further define three categories of observation mode, according to the objects that we observe: a version of a target object represents a consistent stage in its evolution; it is agreed between users or accepted by the system as such, and is normally stored persistently; object versions are named by the pair (global identifier of target object, version number) a snapshot of a target object again represents a stage in its evolution, but one which may be between (consistent, persistent) versions a live replica of an object is a snapshot that is systematically updated on a besteffort basis whenever the object is updated elsewhere (through another live replica). We have distinguished synchronous and asynchronous groupware applications. In general, however, applications do not fall exclusively into one category or another. For example, you and I may work on a document together at the same time. Sometimes we write and edit privately without directly interacting with the other, but from time to time we communicate and show one another our latest work. Similarly, you and I may collaboratively draw a new design artefact in real time, and then work separately in refining different parts of it. We characterise an interaction mode from the point of view of a given user at a given , by listing the set of objects for which she has some object-information mode, and describing that mode. For example, at 10am Jim views a live replica of a spreadsheet in read-write mode and a snapshot of a report he is working on, and talks with Mary over an audio channel about a previous version of the report. Mary views a live replica of the same spreadsheet, also in read-write mode, and the previous version of the report; she is also observing notifications about other users actions concerning information upon which the spreadsheet depends. She corresponds by email with the other users. Two frequently used ways in which users work with a shared object are mutual interaction and separation, which we now define.
user1 notifications separation user2 user3 communication mutual interaction user4

Figure 2. Users 1 & 2 are working in separation mode; users 3 & 4 mutually interacting. Mutual interaction. During mutual interaction users view live replicas of the object or objects concerned and communicate directly. The term what-you-see-is-what-I-see (WYSIWIS) is often used in this connection. But it would be more accurate to require what-you-view-is-what-I-view (WYVIWIV ) we observe the same target objects, but may use different views. Jim and Mary mutually interact over the spreadsheet in the example we described. An important example of mutual interaction is task agreement, where several users examine a collection of objects and explain and negotiate a set of tasks.

11

A task is an agreed transformation applied to a collection of target objects. The user or users executing a task do not necessarily know in advance the set of operations they will perform to realise the transformation. For example, Jim and Mary agree to write separate sections of the report, without knowing what they will write. A group of people who are mutually interacting often do not require system support for consistency, as long as precious data are secured by the system supplying an undo operation. Updates to shared objects may be performed using an ordered multicast of ordering strength appropriate to the application. With turn-taking only FIFO ordering is necessary. The notion of automatically undoing the actions of several users is problematic, given that the actions are not serialised. It seems preferable for the users to agree explicitly on versions of shared objects, to which they may revert. Given that less than total ordering is used, it may be desirable for users to see others replicas of shared objects in order to decide from which to make a version, and for all users to be synchronised with the same snapshot. In a shared virtual environment, however, version-taking and the undo operation are plainly impossible. At least a causal multicast and a willingness for users to accept unreal states of affairs (such as objects appearing momentarily to travel through walls) seem unavoidable. Separation. Under conditions of separation users work on their own or in subgroups to create a new version of the target object. Separation is different from transactional isolation. In separation users belonging to a subgroup may view live replicas of the object, but users outside the separated subgroup do not normally see the changes (although they may obtain snapshots). Either locking or optimistic concurrency control may be used under conditions of separation. Separation ends when: a subgroup observes or is notified of a change made by another unit which requires direct communication with the other user or users a subgroup needs to clarify its task with other users a subgroup completes its task, and either it needs feedback from other users, or it attempts to re-integrate its changes and a conflict with another units changes becomes apparent. Note that a system cannot easily detect shifts between separation and mutual interaction. Even though a user has opened up a communication channel with another user, the channel may be for a purpose unrelated to the task, or it may fall into disuse. Note also that there are interaction modes other than mutual interaction or separation. For example, Jim and Marys supervisor, Fred, may monitor their activity by viewing live replicas of the documents that they are producing, but without communicating with either of them.

6. Conclusion
The arguments made in these notes suggest the following conclusions concerning a framework to support groupware: conventional transactions are in general unsuited to groupware; the only generally required properties of transactions are the CD properties, consistency and durability the system should allow for locking, but should support optimistic techniques as the main concurrency control mechanisms, enhanced with notification and conflict resolution tools

12

the system should support all three object-information modes direct and indirect communication and observation, and all three observation modes observation of versions, snapshots and live replicas the system should recognise that users change dynamically between objectinformation modes and between observation modes two important interaction modes (representing choices of object-information modes by two or more users) are mutual interaction and separation. Tim Kindberg, January 1996.

References
[Achmatowicz and Kindberg 1995] Achmatowicz, R., and Kindberg, T. Object groups for groupware applications: application requirements and design issues, Proc. European research seminar on advances in distributed systems, Mar. 1995, pp. 269-274. [Bentley et al 1992] Bentley, R., Rodden, T., Sawyer, P., and Sommerville, I. An architecture for tailoring cooperative multi-user displays, Proc. CSCW 92, Nov. 1992, pp. 187-194. [Dourish and Bellotti 1992] Dourish, P., and Bellotti, V. Awareness and coordination in shared workspaces, Proc. CSCW 92, Nov. 1992, pp. 107-114. [Dourish 1995a] Dourish, P. Developing a reflective model of collaborative systems, ACM transactions on computer-human interaction, vol. 2 no. 1, Mar. 1995, pp. 40-63. [Dourish 1995b] Dourish, P. Consistency guarantees: exploiting application semantics for consistency management in a collaboration toolkit, tech. report, Rank Xerox Research Centre, Cambridge Laboratory (EuroPARC), 1995. [Ege and Ellis 1987] Ege, A., and Ellis, C. Design and implementation of Gordion, an object base management system. Proc. 3rd international conference on data engineering, IEEE, 1987, pp. 226-234. [Greenberg 1993] Greenberg, S., and Marwood, D. Real-time groupware as a distributed system: concurrency control and its effect on the interface, Research report 94/534/03, Dept. of Computer Science, University of Calgary, Feb. 1993. [Greif and Sarin 1988] Greif, I., and Sarin, S. Data sharing in group work, Chapter 17 of Computer-supported cooperative work: a book of readings, Greif, I., ed., Morgan Kaufmann, 1988. [Grief et al 1986] Greif, I., Seliger, R., and Weihl, W. Atomic data abstractions in a distributed collaborative editing system, Proc. 13th annual symposium on the principles of programming languages, pp. 160-172, 1986. [Kindberg 1995] Kindberg, T. A sequencing service for group communication, Proc. 14th Annual ACM Symposium on Principles of Distributed Computing, Aug. 1995, p. 260. [Kindberg 1996] Kindberg, T. Mushroom: Definition and Architecture, version 1.0, to be made available as a technical report. [Leland et al 1988] Leland, M., Fish, R. and Kraut, R. Collaborative document production using Quilt, Proc. CSCW 88, Sep. 1988.

13

[Mafeis 1994]

Maffeis, S., Bischofberger, W., and Ma tzel, K. GTS: a generic multicast transport service, UBILAB technical report 94.6.1, 1994. [Narayanaswamy and Goldman 1992] Narayanaswamy, K., and Goldman, N., Lazy consistency: a basis for cooperative software development, Proc. CSCW 92, Nov. 1992, pp. 257-264. [Skarra et al 1986] Skarra, A., Zdonik, S., and Reiss, S. An object server for an objectoriented databse system. Proc. international workshop on objectoriented database systems, pp. 196-204, Sep. 1986. [Terry et al 1995] Terry, D., Theimer, M., Peterson, K., Demers, A., Spreitzer, M., and Hauser, C. Managing update conflicts in a weakly connected replicated storage system, Proc. 15th ACM symposium on operating systems principles, pp. 172-183, Dec. 1995.

14