Concurrency control

About: Concurrency control is a research topic. Over the lifetime, 5112 publications have been published within this topic receiving 107438 citations.

Concurrency Control and Consistency of Multiple Copies of Data in Distributed Ingres

Abstract: This paper contains algorithms for ensuring the consistency of a distributed relational data base subject to multiple, concurrent updates. Also included are mechanisms to correctly update multiple copies of objects and to continue operation when less than all machines in the network are operational. Together with [4] and [12], this paper constitutes the significant portions of the design for a distributed data base version of INGRES.

System Level Concurrency Control for Distributed Database Systems

Abstract: A distributed database system is one in which the database is spread among several sites and application programs “move” from site to site to access and update the data they need. The concurrency control is that portion of the system that responds to the read and write requests of the application programs. Its job is to maintain the global consistency of the distributed database while ensuring that the termination of the application programs is not prevented by phenomena such as deadlock. We assume each individual site has its own local concurrency control which responds to requests at that site and can only communicate with concurrency controls at other sites when an application program moves from site to site, terminates, or aborts.This paper presents designs for several distributed concurrency controls and demonstrates that they work correctly. It also investigates some of the implications of global consistency of a distributed database and discusses phenomena that can prevent termination of application programs.

An algorithm for concurrency control and recovery in replicated distributed databases

Abstract: In a one-copy distributed database, each data item is stored at exactly one site. In a replicated database, some data items may be stored at multiple sites. The main motivation is improved reliability: by storing important data at multiple sites, the DBS can operate even though some sites have failed.This paper describes an algorithm for handling replicated data, which allows users to operate on data so long as one copy is “available.” A copy is “available” when (i) its site is up, and (ii) the copy is not out-of-date because of an earlier crash.The algorithm handles clean, detectable site failures, but not Byzantine failures or network partitions.

Deadlock control methods in automated manufacturing systems

Abstract: As more and more producers move to use flexible and agile manufacturing as a way to keep them with a competitive edge, the investigations on deadlock resolution in automated manufacturing have received significant attention for a decade. Deadlock and related blocking phenomena often lead to catastrophic results in automated manufacturing systems. Their efficient handling becomes a necessary condition for a system to gain high productivity. This paper intends to present a tutorial survey of state-of-the art modeling and deadlock control methods for discrete manufacturing systems. It presents the updated results in the areas of deadlock prevention, detection and recovery, and avoidance. It focuses on three modeling methods: digraphs, automata, and Petri nets. Moreover, for each approach, the main and relevant contributions are selected enlightening pros and cons. The paper concludes with the future research needs in this important area in order to bridge the gap between the academic research and industrial needs.

OLTP through the looking glass, and what we found there

Abstract: Online Transaction Processing (OLTP) databases include a suite of features - disk-resident B-trees and heap files, locking-based concurrency control, support for multi-threading - that were optimized for computer technology of the late 1970's Advances in modern processors, memories, and networks mean that today's computers are vastly different from those of 30 years ago, such that many OLTP databases will now fit in main memory, and most OLTP transactions can be processed in milliseconds or less Yet database architecture has changed littleBased on this observation, we look at some interesting variants of conventional database systems that one might build that exploit recent hardware trends, and speculate on their performance through a detailed instruction-level breakdown of the major components involved in a transaction processing database system (Shore) running a subset of TPC-C Rather than simply profiling Shore, we progressively modified it so that after every feature removal or optimization, we had a (faster) working system that fully ran our workload Overall, we identify overheads and optimizations that explain a total difference of about a factor of 20x in raw performance We also show that there is no single "high pole in the tent" in modern (memory resident) database systems, but that substantial time is spent in logging, latching, locking, B-tree, and buffer management operations