New hardware platforms, e.g. cloud, multi-core, etc., have led to a
reconsideration of database system architecture. Our Deuteronomy project
separates transactional functionality from data management functionality,
enabling a flexible response to exploiting new platforms. This separation
requires, however, that recovery is described logically. In this paper, we
extend current recovery methods to work in this logical setting. While this is
straightforward in principle, performance is an issue.
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.