A database system is perhaps the first system that comes to mind when considering support for multiuser interaction. In this paper, we use the term ``database system'' for a traditional relational database system. The following two sections address some of the properties of ``next generation systems'' [Cac91].
Research in relational systems has shown that it is possible to create a tool
that provides a repository of relational data that can be read and modified concurrently by multiple client processes executing on behalf of different users, allows its clients to group data accesses into transactions, provides concurrency control to ensure that transactions are executed atomically, offers access control to prevent unauthorized access, creates efficient data structures for storing large amounts of data, replicates data at distributed sites [Bha89], stores data in main memory [Leh86], and provides a relational query language for accessing and manipulating data.
Figure 8.2 shows how a database system can be used to develop a multiuser application.
The multiuser application is composed of multiple database clients, each of which interacts with a particular user of the application and uses the database to store the data shared among the users (Figure 8.2). When one of the users commits changes to shared state, the corresponding client stores the new values in the database,
from where the remote clients retrieve them and display them to their users. Figure 8.3 shows the main components of the program executed by the database client.
There are several advantages in using a database system for developing multiuser applications. The system relieves its clients from implementing concurrency control.
It also allows clients to make high-level access control specifications and provides the mechanisms required to implement these specifications.
Furthermore, a database system can adopt the replicated approach to allow clients to read data without encountering network delays. Finally, unlike all the other tools discussed later, it provides efficient storage of large amounts of data and a predicate-based query language to access them. Our experience shows that implementing even simple queries can be a non-trivial task if a database system is not used [Dew93a].
However, in comparison to some of the other tools discussed later, a database system has two main disadvantages. First, a database system and its clients use different representations of data. As a result, the database approach forces its clients to convert between different representations of data, which is referred to as the ``impedance mismatch'' problem [Atk87]. Impedance mismatch makes the overhead of developing multiuser applications high since programmers must write translation code that converts between the different representations.
It also increases the response time of the applications because of the overhead of executing the translation code at runtime, which must perform costly join operations in case of structured data such as parse trees [Lin84]. Impedance mismatch is also a problem in single-user applications that use the database to store their persistent data. It is a more severe problem in multiuser applications developed using this approach since they use the database to also store shared, possibly non-persistent, data such as scrollbar positions.
Second, in highly collaborative tasks, users are often interested in receiving changes to shared data as soon as they are made available to them.
Under this approach, such collaboration can only be supported if each client listening for changes frequently polls the database system for the changes, thereby making the client more difficult to program and, more important, drastically degrading the performance of the system [Dew90b]. The cost of polling together with the cost of impedance mismatch makes this technology unsuitable for highly concurrent collaborative tasks.
Implementing the example user-interface: To make the discussion concrete, consider implementation of the example user-interface (Figure 8.1) using a database system.
A separate client is created for each user, which creates the two windows displayed on the user's workstation, processes input events generated by the workstation, and generates output requests for the workstation. The shared data such as the semantic state of the edit windows and the complete state of the test windows is kept in the database. The clients specify the rights of the different users to the edit procedures and other shared data--the database system provides the access control procedures required to implement these specifications. The database system also provides concurrency control procedures required to ensure that changes to a shared datum are not made concurrently by different clients. Furthermore, it provides a predicate-based query language for retrieving coverage and other information from the database. The parse trees of edit procedures and other shared data are represented internally in clients using some general purpose programming language. The clients translate between the programming language and database representations of these data. The overhead of polling and performing this translation makes it unsuitable to use this application to support highly collaborative interaction such as one in which the procedures in the edit windows are changed frequently or the test windows are scrolled frequently.
Several of the drawbacks of database systems arise because they were designed to support individual interaction and not collaborative interaction.
We discuss below tools that are more appropriate for implementing collaborative interaction.
