Databases Reference
In-Depth Information
Users; Physical World Actions & Effects
Physical World
Cyber Space
The Transaction Scope of
Applications
Data Sources
(databases, files,
persistent object
stores, etc.)
Non-transactional Actions
Fig. 1.
Transaction Level Scope of Applications
Client
App
App Server
Transaction
Interface
Web
Server
Data Stores
Fig. 2.
The Transaction Model in Concern
they are typically stateful and data-intensive; they are typically 24*7 applica-
tions requiring superb business continuity (i.e., availability); and they typically
require guaranteed recoverability (and data integrity).
Although the DQR problem may be addressed at several abstraction lev-
els (e.g., disk level, OS level, DBMS level, transaction level, application level),
solving the DQR problem at the transaction level is particularly appealing due
to the following reasons. The
transaction
abstraction has revolutionized the
way
reliability
, including
recoverability
, is engineered for applications. Through
a simple API interface provided by an easy-to-use transaction (processing)
package which is today an integral part of mainstream application develop-
ment environments such as J2EE and .NET, programmers can make applica-
tions
transactional
in a rather automatic, effort-free fashion. And the benefits
of making applications transactional are significant: “failure atomicity sim-
plifies the maintenance of invariants on data” [2]; a guaranteed level of data
consistency can be achieved without worrying about say race conditions; dura-
bility makes it much easier for programmers to get the luxury of recoverability.
As a result, the transaction mechanism is embraced by not only database
systems [3], but also a large variety of computer systems and applications [4],
including operating systems (e.g., VINO provides kernel transaction support
[5]), file systems (e.g., Camelot provides transactional access to user-developed
data structures stored in files [2]; and [6] argues that transactional file sys-
tems can be fast), distributed systems (e.g., QuickSilver uses transactions as
a unified failure recovery mechanism [7]), persistent object stores (e.g., Augus
supports transactions on abstract objects [8]), CORBA, and Web Services.
To leverage the strength, recovery facilities, and popularity of the trans-
action mechanism, and more important to make the proposed DQR so-
