Cooperative memory and database transactions

Dissertação apresentada na Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa para a obtenção do Grau de Mestre em Engenharia InformáticaSince the introduction of Software Transactional Memory (STM), this topic has received a strong interest by the scientific community, as it has the potential of greatly facilitating concurrent programming by hiding many of the concurrency issues under the transactional layer, being in this way a potential alternative to the lock based constructs, such as mutexes and semaphores. The current practice of STM is based on keeping track of changes made to the memory and, if needed, restoring previous states in case of transaction rollbacks. The operations in a program that can be reversible,by restoring the memory state, are called transactional operations. The way that this reversibility necessary to transactional operations is achieved is implementation dependent on the STM libraries being used. Operations that cannot be reversed,such as I/O to external data repositories (e.g., disks) or to the console, are called nontransactional operations. Non-transactional operations are usually disallowed inside a memory transaction, because if the transaction aborts their effects cannot be undone. In transactional databases, operations like inserting, removing or transforming data in the database can be undone if executed in the context of a transaction. Since database I/O operations can be reversed, it should be possible to execute those operations in the context of a memory transaction. To achieve such purpose, a new transactional model unifying memory and database transactions into a single one was defined, implemented, and evaluated. This new transactional model satisfies the properties from both the memory and database transactional models. Programmers can now execute memory and database operations in the same transaction and in case of a transaction rollback, the transaction effects in both the memory and the database are reverted

Concurrency Control in Advanced Database Applications

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 non-serializable cooperation among users whose transactions are long-lived 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

Concurrency Control in Advanced Database Applications

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 non-serializable cooperation among users whose transactions are long-lived 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

S-Store: Streaming Meets Transaction Processing

Stream processing addresses the needs of real-time applications. Transaction processing addresses the coordination and safety of short atomic computations. Heretofore, these two modes of operation existed in separate, stove-piped systems. In this work, we attempt to fuse the two computational paradigms in a single system called S-Store. In this way, S-Store can simultaneously accommodate OLTP and streaming applications. We present a simple transaction model for streams that integrates seamlessly with a traditional OLTP system. We chose to build S-Store as an extension of H-Store, an open-source, in-memory, distributed OLTP database system. By implementing S-Store in this way, we can make use of the transaction processing facilities that H-Store already supports, and we can concentrate on the additional implementation features that are needed to support streaming. Similar implementations could be done using other main-memory OLTP platforms. We show that we can actually achieve higher throughput for streaming workloads in S-Store than an equivalent deployment in H-Store alone. We also show how this can be achieved within H-Store with the addition of a modest amount of new functionality. Furthermore, we compare S-Store to two state-of-the-art streaming systems, Spark Streaming and Storm, and show how S-Store matches and sometimes exceeds their performance while providing stronger transactional guarantees

Transaction processing in real-time database systems

Scheduling transactions in a real-time database requires an integrated approach in which the schedule does not only guarantee execution before the deadline, but also maintains data consistency. The problem has been studied under a common framework which considers both concurrency control issues and the real-time constraints in centralized and distributed transaction processing. A real-time transaction processing model has been defined for a centralized system. The proposed protocols use a unified approach to maximize concurrency while meeting real-time constraints at the same time. In order to test the behavior of the model and the proposed protocols, a real-time transaction processing testbed has been developed using discrete event simulation techniques. The results indicate that different protocols work better under different load scenarios and that the overall performance can be significantly enhanced by modifying the underlying system configuration. Among other system and transaction parameters, the effect of data partitioning, buffer management, preemption, disk contention, locking mode and multiprocessing has been studied;For the distributed environment, new concepts of real-time nested transactions and priority propagation have been proposed. Real-time nested transactions incorporate the deadline requirements in the hierarchical structure of nested transactions. Priority propagation addresses the issues related to transaction aborts in real-time nested transaction processing. The notion of priority ceiling has been used to avoid the priority inversion problem. The proposed protocols exhibit freedom from deadlock and have tightly bounded waiting period. Both of these properties make them very suitable for distributed real-time transaction processing environment

Performance Comparison of Various STM Concurrency Control Protocols Using Synchrobench

Writing concurrent programs for shared memory multiprocessor systems is a nightmare. This hinders users to exploit the full potential of multiprocessors. STM (Software Transactional Memory) is a promising concurrent programming paradigm which addresses woes of programming for multiprocessor systems. In this paper, we implement BTO (Basic Timestamp Ordering), SGT (Serialization Graph Testing) and MVTO(Multi-Version Time-Stamp Ordering) concurrency control protocols and build an STM(Software Transactional Memory) library to evaluate the performance of these protocols. The deferred write approach is followed to implement the STM. A SET data structure is implemented using the transactions of our STM library. And this transactional SET is used as a test application to evaluate the STM. The performance of the protocols is rigorously compared against the linked-list module of the Synchrobench benchmark. Linked list module implements SET data structure using lazy-list, lock-free list, lock-coupling list and ESTM (Elastic Software Transactional Memory). Our analysis shows that for a number of threads greater than 60 and update rate 70%, BTO takes (17% to 29%) and (6% to 24%) less CPU time per thread when compared against lazy-list and lock-coupling list respectively. MVTO takes (13% to 24%) and (3% to 24%) less CPU time per thread when compared against lazy-list and lock-coupling list respectively. BTO and MVTO have similar per thread CPU time. BTO and MVTO outperform SGT by 9% to 36%

A Concurrency Control Algorithm for an Open and Safe Nested Transaction Model

We present a concurrency control algorithm for an open and safe nested transaction model. We use prewrite operations in our model to increase the concurrency. Prewrite operations are modeled as subtransactions in the nested transaction tree. The subtransaction which initiates prewrite subtransactions are modelled as recovery point subtransaction. The recovery point subtransaction can release their locks before its ancestors commit. Thus, our model increases the concurrency in comparison to other nested transaction models. Our model is useful an environment of long-running transactions common in object oriented databases, computer aided design and in the software development proces