Results 1 -
7 of
7
Principles of Transaction-Oriented Database Recovery
- ACM Computing Surveys
, 1983
"... In this paper, a terminological framework is provided for describing different transaction-oriented recovery schemes for database systems in a conceptual rather than an implementation-dependent way. By introducing the terms materialized database, propagation strategy, and checkpoint, we obtain a mea ..."
Abstract
-
Cited by 222 (4 self)
- Add to MetaCart
In this paper, a terminological framework is provided for describing different transaction-oriented recovery schemes for database systems in a conceptual rather than an implementation-dependent way. By introducing the terms materialized database, propagation strategy, and checkpoint, we obtain a means for classifying arbitrary
File System Performance and Transaction Support
, 1992
"... This thesis considers two related issues: the impact of disk layout on file system throughput and the integration of transaction support in file systems. Historic file system designs have optimized for reading, as read throughput was the I/O performance bottleneck. Since increasing main-memory cach ..."
Abstract
-
Cited by 28 (3 self)
- Add to MetaCart
This thesis considers two related issues: the impact of disk layout on file system throughput and the integration of transaction support in file systems. Historic file system designs have optimized for reading, as read throughput was the I/O performance bottleneck. Since increasing main-memory cache sizes effectively reduce disk read traffic [BAKER91], disk write performance has become the I/O performance bottleneck [OUST89]. This thesis presents both simulation and implementation analysis of the performance of read-optimized and write-optimized file systems. An example of a file system with a disk layout optimized for writing is a log-structured file system, where writes are bundled and written sequentially. Empirical evidence in [ROSE90], [ROSE91], and [ROSE92] indicates that a log-structured file sys...
Vino: an integrated platform for operating systems and database research
, 1994
"... In 1981, Stonebraker wrote: Operating system services in many existing systems are either too slow or inappropriate. Current DBMSs usually provide their own and make little or no use of those o ered by the operating system. [STON81] The standard operating system model has changed little since that t ..."
Abstract
-
Cited by 25 (2 self)
- Add to MetaCart
In 1981, Stonebraker wrote: Operating system services in many existing systems are either too slow or inappropriate. Current DBMSs usually provide their own and make little or no use of those o ered by the operating system. [STON81] The standard operating system model has changed little since that time, and we believe that, at its core, it is the wrong model for DBMS and other resource-intensive applications. The standard model is in exible, uncooperative, and irregular in its treatment of resources. We describe the design of a new system, the VINO kernel, which addresses the limitations of standard operating systems. It focuses on three key ideas: Applications direct policy. Kernel mechanisms are reusable by applications. All resources share a common extensible interface. VINO's power and exibility make it an ideal platform for the design and implementation of traditional and modern database management systems. 1
Transaction Support in Read Optimized and Write Optimized File Systems
- Proceedings of the 16th International Conference on Very Large Data Bases
, 1990
"... This paper provides a comparative analysis of five implementations of transaction support. The first of the methods is the traditional approach of implementing transaction processing within a data manager on top of a read optimized file system. The second also assumes a traditional file system but e ..."
Abstract
-
Cited by 24 (5 self)
- Add to MetaCart
This paper provides a comparative analysis of five implementations of transaction support. The first of the methods is the traditional approach of implementing transaction processing within a data manager on top of a read optimized file system. The second also assumes a traditional file system but embeds transaction support inside the file system. The third model considers a traditional data manager on top of a write optimized file system. The last two models both embed transaction support inside a write optimized file system, each using a different logging mechanism. Our results show that in a transaction processing environment, a write optimized file system often yields better performance than one optimized for reads. In addition, we show that file system embedded transaction managers can perform as well as data managers when transaction throughput is limited by I/O bandwidth. Finally, even when the CPU is the critical resource, the difference in performance between a data manager an...
LIBTP: Portable, modular transactions for UNIX
- Proceedings of the 1992 Winter Usenix
, 1992
"... Transactions provide a useful programming paradigm for maintaining logical consistency, arbitrating concurrent access, and managing recovery. In traditional UNIX systems, the only easy way of using transactions is to purchase a database system. Such systems are often slow, costly, and may not provid ..."
Abstract
-
Cited by 22 (8 self)
- Add to MetaCart
Transactions provide a useful programming paradigm for maintaining logical consistency, arbitrating concurrent access, and managing recovery. In traditional UNIX systems, the only easy way of using transactions is to purchase a database system. Such systems are often slow, costly, and may not provide the exact functionality desired. This paper presents the design, implementation, and performance of LIBTP, a simple, non-proprietary transaction library using the 4.4BSD database access routines (db(3)). On a conventional transaction processing style benchmark, its performance is approximately 85 % that of the database access routines without transaction protection, 200 % that of using fsync(2) to commit modifications to disk, and 125 % that of a commercial relational database system. 1.
Transaction Support in a Log-Structured File System
- Proceedings of the Ninth International Conference on Data Engineering
, 1993
"... This paper presents the design and implementation of a transaction manager embedded in a log-structured file system [11]. Measurements show that transaction support on a log-structured file system offers a 10% performance improvement over transaction support on a conventional, read-optimized file sy ..."
Abstract
-
Cited by 20 (4 self)
- Add to MetaCart
This paper presents the design and implementation of a transaction manager embedded in a log-structured file system [11]. Measurements show that transaction support on a log-structured file system offers a 10% performance improvement over transaction support on a conventional, read-optimized file system. When the transaction manager is embedded in the log-structured file system, the resulting performance is comparable to that of a more traditional, user-level system. The performance results also indicate that embedding transactions in the file system need not impact the performance of nontransaction applications. 1. Introduction Traditionally, transaction support has been provided by database management systems running as user-level processes. These systems maintain their own cache of frequently accessed data pages and perform their own scheduling, allowing multiple processes to access a single database. When transaction support is provided as an operating system service, concurrency ...
VINO: The 1994 Fall Harvest
, 1994
"... Current operating systems are designed to provide leastcommon -denominator service to a variety of applications. They export few internal kernel facilities, and those which are exported have irregular interfaces. As a result, resource intensive applications such as database management systems and mu ..."
Abstract
-
Cited by 17 (0 self)
- Add to MetaCart
Current operating systems are designed to provide leastcommon -denominator service to a variety of applications. They export few internal kernel facilities, and those which are exported have irregular interfaces. As a result, resource intensive applications such as database management systems and multimedia applications, are often poorly served by the operating system. These applications often go to great lengths to bypass normal kernel mechanisms to achieve acceptable performance. We describe a new kernel architecture, the VINO kernel, which addresses the limitations of conventional operating systems. The VINO design is driven by three principles: ffl Application Directed Policy: the operating system provides a collection of mechanisms, but applications dictate the policies applied to those mechanisms. ffl Kernel as Toolbox: applications can reuse the kernel's primitives. ffl Universal Resource Access: all resources are accessed through a single, common interface. VINO's power and...

