Formal Aspects of Serializability in Database Concurrency Control

Bernstein, Philip A.; Shipman, David W.; Wong, Wing Shing

doi:10.1109/tse.1979.234182

Cited by 194 publications

(89 citation statements)

References 4 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Two-phase locking (2PL) was the first provably correct method of ensuring the correct execution of concurrent transactions in a database system [6,12]. Under this scheme, transactions have to acquire locks for a particular element in the database before they are allowed to execute a read or write operation on that element.…”

Section: Two-phase Lockingmentioning

confidence: 99%

Staring into the abyss

Yu¹,

Bezerra²,

Pavlo

et al. 2014

Proc. VLDB Endow.

173

View full text Add to dashboard Cite

Computer architectures are moving towards an era dominated by many-core machines with dozens or even hundreds of cores on a single chip. This unprecedented level of on-chip parallelism introduces a new dimension to scalability that current database management systems (DBMSs) were not designed for. In particular, as the number of cores increases, the problem of concurrency control becomes extremely challenging. With hundreds of threads running in parallel, the complexity of coordinating competing accesses to data will likely diminish the gains from increased core counts.To better understand just how unprepared current DBMSs are for future CPU architectures, we performed an evaluation of concurrency control for on-line transaction processing (OLTP) workloads on many-core chips. We implemented seven concurrency control algorithms on a main-memory DBMS and using computer simulations scaled our system to 1024 cores. Our analysis shows that all algorithms fail to scale to this magnitude but for different reasons. In each case, we identify fundamental bottlenecks that are independent of the particular database implementation and argue that even state-of-the-art DBMSs suffer from these limitations. We conclude that rather than pursuing incremental solutions, many-core chips may require a completely redesigned DBMS architecture that is built from ground up and is tightly coupled with the hardware.

show abstract

Section: Two-phase Lockingmentioning

confidence: 99%

Staring into the abyss

Yu¹,

Bezerra²,

Pavlo

et al. 2014

Proc. VLDB Endow.

173

View full text Add to dashboard Cite

show abstract

“…As in [6], we consider that the behavior of a transaction T can be decomposed in three sequential steps 1 : it first reads data objects, then does local computations and finally writes new values in some objects, which means that a transaction can be seen as a software read modify write() operation that is dynamically defined by a process 2 . The read set is defined incrementally, which means that a transaction reads the objects of its read set asynchronously one after the other (between two consecutive reads, the transaction can issue local computations that take arbitrary, but finite, durations).…”

Section: Imbs and M Raynalmentioning

confidence: 99%

A Versatile STM Protocol with Invisible Read Operations That Satisfies the Virtual World Consistency Condition

Imbs

Raynal

2010

Structural Information and Communication Complexity

View full text Add to dashboard Cite

To cite this version:Damien Imbs, Michel Raynal. A versatile STM protocol with invisible read operations that satisfies the virtual world consistency condition. Abstract:The aim of a Software Transactional Memory (STM) is to discharge the programmers from the management of synchronization in multiprocess programs that access concurrent objects. To that end, a STM system provides the programmer with the concept of a transaction. The job of the programmer is to decompose each sequential process the application is made up of into transactions. A transaction is a piece of code that accesses concurrent objects, but contains no explicit synchronization statement. It is the job of the underlying STM system to provide the illusion that each transaction appears as being executed atomically. For efficiency, a STM system allows transactions to execute concurrently. Consequently, due to the underlying STM concurrency management, a transaction commits or aborts. This paper first presents a new STM consistency condition, called virtual world consistency. This condition states that no transaction reads object values from an inconsistent global state. It is similar to opacity for the committed transactions but weaker for the aborted transactions. More precisely, it states that (1) the committed transactions can be totally ordered, and (2) the values read by each aborted transaction are consistent with respect to its causal past only. Hence, virtual world consistency is weaker than opacity while keeping its spirit. Then, assuming the objects shared by the processes are atomic read/write objects, the paper presents a STM protocol that ensures virtual world consistency (while guaranteeing the invisibility of the read operations). From an operational point of view, this protocol is based on a vector-clock mechanism. Finally, the paper considers the case where the shared objects are regular read/write objects. It also shows how the protocol can be weakened to satisfy the causal consistency condition (that is weaker than virtual world consistency).Virtual world consistency does not require the aborted transactions to agree on what they have seen. This is captured by the local vector clocks associated with each process and the vector timestamps associated with each object. From a comprehensive point of view, the paper addresses how the interplay of these local control informations allows the execution of a set of transactions to be provided with a global meaning. Key-words:Atomic object, Causal past, Commit/abort, Concurrency control, Consistency condition, Consistent global state, Lock, Read-from relation, Regular Read/write object, Serializability, Shared memory, Software transactional memory, Vector clock, Transaction.

show abstract

“…4 Although this theorem takes into account the effect of a task being preempted by higher priority tasks, it does not consider the effect of blocking caused by lower priority tasks upon schedulability analysis. We now consider the effect of blocking.…”

Section: Corollarymentioning

confidence: 99%

“…Both concurrency control [2,3,4,5,7,16,17,18,20,21,23,26] and real-time scheduling algorithms [10,11,13,14,15,19,22,27] are active areas of research in their own right. It may seem that the development of a real-time locking protocol is a simple matter of combining priority scheduling with a locking protocol.…”

Section: Introductionmentioning

confidence: 99%

A real-time locking protocol

Sha

Rajkumar

Son

et al. 1991

IEEE Trans. Comput.

161

View full text Add to dashboard Cite

When a database system is used in a real-time application, the concurrency control protocol must satisfy not only the consistency of shared data but also the timing constraints of the application. In this paper, we examine a prioritydriven two-phase lock protocol called the read-or write-priority ceiling protocol. We show that this protocol is free of deadlock, and in addition a high-priority transaction can be blocked by lower priority transactions for at most the duration of a single embedded transaction. We then evaluate system performance experimentally.

show abstract

Formal Aspects of Serializability in Database Concurrency Control

Cited by 194 publications

References 4 publications

Staring into the abyss

Staring into the abyss

A Versatile STM Protocol with Invisible Read Operations That Satisfies the Virtual World Consistency Condition

A real-time locking protocol

Contact Info

Product

Resources

About