By | June 20, 2015


The first widely adopted approach to coordination in a collaborative environment is to pessimistically assume that users within the system will desire to edit the same object at the same time and that such edits will be destructive or cause problems. Since this is a shared resource/object, consistency and causality are important. Notice the similarity to causal memory, shared memory, and cache coherency in distributed systems research.

Pessimistic coordination policies are typically implemented using a “check in” and “check out” API. Users may gain access to an unused document by issuing a “check out” request; the document is then locked for that user, and no other user may access the document. When a user has completed any edits to a checked out document, he may issue a “check in” request, returning the document to the repository with any changes made to the local copy.

Since only one user has access to the shared document at any given time, the problem of multiple versions of the same document within the system is avoided. Thus, no two users can have writable copies checked out at the same time. Updates to the repository occur upon a “check in” command, and the old copy of the document is overwritten with the new copy of the document. Often, differentials are saved so that “undo” or “revert to old version” commands are possible. The following figure illustrates this.

One major limitation of the pessimistic coordination policy is the lack of concurrency in the distributed environment; since only one user can access each shared document at a time, then concurrency of collaboration may be inhibited. A few solutions to this problem exist:

First, one can reduce the size of the code placed into each atomic element within the repository. Since each element (document) within the repository contains less code, the probability of two users requesting the same document may be reduced. This is akin to breaking up a large file into smaller files, each of which may be checked out concurrently without being inhibited by the pessimistic locking policy. Of course, it may not always be possible to create small documents within the repository, and a highly-desired document may inhibit concurrency regardless of its size.

Second, configuration management repositories may allow users to check out “read only” copies of an already-checked-out document. I.e. if one user already owns a document, other users may view (but not edit) the contents of this document. Such a local copy could be used within local users’ workspaces for “what if” editing without corrupting the original, master copy. If such local changes are deemed relevant to the master copy, the user can later check out the master and incorporate these changes.

The second widely used approach to coordinating concurrent development in a shared space is the optimistic approach. This coordination policy assumes optimistically that users will not need to access the same resource at the same time frequently [Magnusson, 1993; O’Reilly, 2003], thus this policy promotes increased concurrency among collaboration at the cost of potential problems in inconsistency in the shared documents and loss of causal access. Such a policy is indicative of and seems to work well in an “agile development” environment where communication and productiveness trump tools, processes, and planning [O’Reilly, 2004].

Optimistic coordination systems are typically implemented using awareness within the system such that users are made aware of each others’ activities. Awareness is defined as “an informal understanding of the activity of others that provides a context for monitoring and assessing group and individual activities” [van der Hoek et al, 1996]. In such a system, synchronous updates occur immediately when an edit occurs (akin to a write through cache policy in distributed shared memory systems). Consequently, all users have a current copy of any shared document and no check-in and check-out is needed because any document a user is editing is by definition checked out (and perhaps checked out simultaneously by many users) [O’Reilly, 2004]. The following figure illustrates the optimistic coordination policy.

Such awareness-based optimistic systems rely upon users to coordinate and avoid collisions in edits to the shared document. According to current CSCW research, this seems to work reasonably well in smaller work groups, but does not scale well to larger collaborations among many users [van der Hoek, 1996]. Two proposed reasons for this include the limited amount of cognitive information users may process simultaneously and the inherent dichotomy of informal coordination and formal, process-driven coordination.

Consequently, optimistic coordination policies work well in smaller collaborative environments with fewer users when self-coordination is accomplished by the users of the system. The advantage of such an approach is increased collaboration and concurrency.

Leave a Reply

Your email address will not be published. Required fields are marked *