Cloud Computing publication categorizer

The traditional architecture for a DBMS engine has the recovery,
concurrency control and access method code tightly bound
together in a storage engine for records. We propose a different
approach, where the storage engine is factored into two layers
(each of which might have multiple heterogeneous instances). A
Transactional Component (TC) works at a logical level only: it
knows about transactions and their ―logical‖ concurrency control
and undo/redo recovery, but it does not know about page layout,
B-trees etc. A Data Component (DC) knows about the physical
storage structure. It supports a record oriented interface that
provides atomic operations, but it does not know about
transactions. Providing atomic record operations may itself
involve DC-local concurrency control and recovery, which can be
implemented using system transactions. The interaction of the
mechanisms in TC and DC leads to multi-level redo (unlike the
repeat history paradigm for redo in integrated engines). This
refactoring of the system architecture could allow easier
deployment of application-specific physical structures and may
also be helpful to exploit multi-core hardware. Particularly
promising is its potential to enable flexible transactions in cloud
database deployments. We describe the necessary principles for
unbundled recovery, and discuss implementation issues.