Java Reference
In-Depth Information
We want to develop a software framework, called RECAP, for tracking
application executions that enables the design and implementation of
recoverable applications, i.e. applications in which relevant state transitions
may be undone or redone upon request or in case of system failures.
Since tracking all state changes produced by an arbitrarily complex appli-
cation may become significantly time-consuming, thus wasting useful com-
putation resources, our recovery framework requires the software designer
to define explicitly the recoverable domain of the application to be tracked,
i.e. the set of classes whose state is significant and has to be recoverable.
After the recoverable domain has been defined, all operations which cause
a state transition for registered classes are recorded in sequence. Hence,
the evolution of an application is modelled as a continuous stream of
modification operations on registered classes.
The RECAP framework should provide a variety of explicit undo
redo
primitives which can be invoked explicitly by the application or under the
user's control.
18.2
Problem analysis
Tracking takes place only for a subset of all the objects manipulated by a
software application. In particular, we call trackable a class whose state
changes are tracked by the system, hence making it possible to undo or redo
its state transitions.
State changes are usually caused by the invocation of methods, which
may perform complex operations affecting several classes of the application.
The framework should offer a set of classes and interfaces that implement
simple mechanisms for recording state transitions occurring in a software
application. The use of these mechanisms must not affect the design of the
recoverable application. Nevertheless, the use of the tracking mechanisms
might affect the application's performance.
18.2.1
Domain models
The problem of recovering from a failure has been traditionally addressed in
the field of database management systems and transaction managers. In the
context of traditional transaction processing, a transaction is defined as an
atomic unit of work, i.e. a sequence of database modification operations
(state transitions) that have to be executed completely or not at all. If the
final state in the sequence is not reached, the DBMS restores its last state
before the beginning of the sequence. The atomicity property is guaranteed
by appropriately registering in a log file (Hulse and Dearle 1998) the
sequence of state transitions (old state
new state) caused by application
data modification requests. The recovery functionality of these systems is
based on the fact that all modification operations (store a value, update a
value, delete a value) can be registered in a log file, by storing (in a compact
-
 
Search WWH ::




Custom Search