Concurrency control in advanced database applications

Naser S. Barghouti, Gail E. Kaiser
<span title="1991-09-01">1991</span> <i title="Association for Computing Machinery (ACM)"> <a target="_blank" rel="noopener" href="" style="color: black;">ACM Computing Surveys</a> </i> &nbsp;
Concurrency control has been thoroughly studied in the context of traditional database applications such as banking and airline reservations systems. There are relatively few studies, however, that address the concurrency control issues of advanced database applications such as CAD/CAM and software development environments. The concurrency control requirements in such applications are different from those in conventional database applications; in particular, there is a need to support
more &raquo; ... izable cooperation among users whose transactions are longlived and interactive, and to integrate concurrency control mechanisms with version and configuration control. This paper outlines the characteristics of data and operations in some advanced database applications, discusses their concurrency control requirements, and surveys the mechanisms proposed to address these requirements. Many large multi-user software systems, such as software development environments, generate and manipulate large amounts of data. SDEs, for example, generate and manipulate source code, object code, documentation, test suites, etc. Traditionally, users of such systems managed the data they generate either manually or by the use of special-purpose tools. For example, programmers working on a large-scale software project use system configuration management tools such as Make [Feldman 79] and RCS [Tichy 85] to manage the configurations and versions of the programs they are developing. Releases of the finished project are stored in different directories manually. The only common interface among all these tools is the file system, which stores project components in text or binary files regardless of their internal structures. 5 This significantly limits the ability to manipulate these objects in desirable ways. It also causes inefficiencies in the storage of collections of objects, and leaves data, stored as a collection of related files, susceptible to corruption due to incompatible concurrent access. Recently, researchers have attempted to utilize database technology to manage the objects belonging to a system uniformly. Design environments, for example, need to store the objects they manipulate (design documents, circuit layouts, programs, etc.) in a database and have it managed by a DBMS for several reasons [Bernstein 87; Dittrich et al. 87; Nestor 86; Rowe and Wensel 89]: 1. Data integration: providing a single data management and retrieval interface for all tools accessing the data. 2. Application orientation: organizing data items into structures that capture much of the semantics of the intended applications. 3. Data integrity: preserving consistency and recovery, to ensure that all the data satisfy the integrity constraints required by the application. 4. Convenient access: providing a powerful query language to access sets of data items at a time. 5. Data independence: hiding the internal structure of data from tools so that if the structure is changed, it will have a minimal impact on the applications using the data. Since there are numerous commercial DBMSs available, several projects have tried to use them in advanced applications. Researchers discovered quite rapidly, however, that even the most sophisticated of today's DBMSs are inadequate for advanced applications [Korth and Silberschatz 86; Bernstein 87]. One of the shortcomings of traditional general-purpose DBMSs is the inability to provide flexible concurrency control mechanisms. To understand the reasons behind this, we need to explain the concepts of transactions and serializability. These two concepts are central to all conventional concurrency control mechanisms. 6 been locked earlier in the transaction, and (2) are divided into a growing phase, in which locks are only acquired, and a shrinking phase, in which locks are only released [Eswaran et al. 76]. During the shrinking phase, a transaction is prohibited from acquiring locks. If a transaction tries during its growing phase to acquire a lock that has already been acquired by another transaction, it is forced to wait. This situation might result in deadlock if transactions are mutually waiting for each other's resources. Tree Protocol Schedule S1:
<span class="external-identifiers"> <a target="_blank" rel="external noopener noreferrer" href="">doi:10.1145/116873.116875</a> <a target="_blank" rel="external noopener" href="">fatcat:7djdmy5phnbazn37wyu7nbulju</a> </span>
<a target="_blank" rel="noopener" href="" title="fulltext PDF download" data-goatcounter-click="serp-fulltext" data-goatcounter-title="serp-fulltext"> <button class="ui simple right pointing dropdown compact black labeled icon button serp-button"> <i class="icon ia-icon"></i> Web Archive [PDF] <div class="menu fulltext-thumbnail"> <img src="" alt="fulltext thumbnail" loading="lazy"> </div> </button> </a> <a target="_blank" rel="external noopener noreferrer" href=""> <button class="ui left aligned compact blue labeled icon button serp-button"> <i class="external alternate icon"></i> </button> </a>