Empress
Technical News - June 2013
Empress SDK for Android – Power Down Recovery
Robust Solution for Android Application Developers
Introduction
Google’s Android has become the choice not just for phones but for
many embedded devices. Similar to other embedded systems, Android
devices are not immune to power down problems. This is particularly
true when Android devices have to deal with storing persistent data
in files, memory or databases. These problems are more complex in
the situations when power goes down and database tasks have been
interrupted and left unfinished transactions or data manipulation in
databases. This may result in databases that are in an inconsistent
state on reboot.
Hence, Android application developers need to know how to deal with
database inconsistencies due to unexpected power downs.
Empress SDK for Android allows Android application developers to
create embedded database driven applications with specific solutions
for power down recovery situations.
A Typical Empress Android application is shown in Figure
1. Here an Android device is running a database driven
application containing the Empress JDBC Local Access Driver with the
Empress Database engine to execute database tasks against Empress
databases on the Android device.
Figure 1:
Typical Empress Android application
What happens when the Android Device Powers Down
In a normal power down process, the Android O/S typically sends
notifications or invokes callback functions to Empress Applications
so that they have enough time to close databases and terminate
gracefully. Hence, in most cases, nothing needs to be done when
power comes back up again. Empress databases will be ready to be
used right away.
In the case of an abrupt Android O/S power down, the Android O/S may
send signals such as SIGKILL to the Empress Database Engine. Empress
Applications will NOT have enough time to clean-up and terminate
gracefully. Empress provides an Empress Database Integrity Assurance
facility called
for these situations. The application program can invoke checkAndRepair to
check and recover databases to a consistent state.
On an abrupt power down or severe interrupt, Empress applications
may have dangling clients left in the database coordinator, dangling
transactions, dangling locks, etc. Running
when the system is powered on can quickly sort out many of those
problems with quickCheck
option enabled. In the event of more stubborn problems, running
with the quickCheck
option disabled, which takes longer, since full check and
repair will be performed, would be a solution.
checkAndRepair
is part of the set of Empress Callable Administration functions
which are outlined below.
Using Empress Callable Administration Functions in Java
The following functions are supported via the class DatabaseAdmin:
DatabaseAdmin.setEnv - set Empress system
variables
DatabaseAdmin.createDB - create a database
DatabaseAdmin.removeDB - remove a database
DatabaseAdmin.exportDB - export table(s) from a
database
DatabaseAdmin.importDB - import table(s) into a
database
DatabaseAdmin.checkAndRepair - check and repair database issues
Empress Callable Administration Functions can be invoked by the
application for full control of running database administration
tasks.
How checkAndRepair Works
checkAndRepair
is an Empress database integrity assurance facility that reports and
repairs database inconsistencies. Problems with dangling locks,
transactions, temporary files, coordinator information and other
database problems can be detected and resolved.
checkAndRepair
performs the following operations in phases:
PHASE 1: Recreating shared memory as necessary
PHASE 2: Find all clients which terminated improperly
PHASE 3: Check semaphores
PHASE 4: Resolve transactions
PHASE 5: Resolve locks
PHASE 6: Check compiled data dictionary REL file
PHASE 7: Generate compile entries for data dictionary
PHASE 8: Check data dictionary REL/DTF files
PHASE 9: Rebuild indices on system tables
PHASE 10: Recompile null entries in data dictionary
PHASE 11: Recompile all entries in data dictionary
PHASE 12: Check data dictionary tables for consistency
PHASE 13: Check database files for consistency
PHASE 14: Check TMP_*_TAB_* tables
PHASE 15: Check REL/DTF files
PHASE 16: Check coordinator
PHASE 17: Rebuild indices on user tables
PHASE 18: Purge replication table records if necessary
PHASE 19: Check directories for temporary files
checkAndRepair
supports quick
check and full
check. quick
check only executes Phases 1,2,3,4,5 and16 while
executes all phases except phase 10, since phase 11 overwrites phase
10.
checkAndRepair
has the following syntax:
int DatabaseAdmin.checkAndRepair (String dbName,
boolean quickCheck, String dbKey)
where
dbName: the physical path to the database to be
imported.
quickCheck: if true, perform a quick but not
thorough check and repair.
If false, perform a full check and repair.
dbKey the cipher key of the database if the
database is encrypted,
otherwise, it is null.
Return Value: If the value is 1 it indicates the
method found
problem(s) and fixed them. If the value is 0 it
indicates that the
method didn’t find a problem.
Problems with dangling locks, transactions, temporary files,
coordinator information, indexes and other database problems can be
detected and resolved by checkAndRepair.
Benchmarking Performance of checkAndRepair
To give Android developers some feeling of
checkAndRepair performance on
different Android devices, a benchmark was performed. The benchmark
was done on the following Android devices:
1. Google Nexus One Phone
2. ViewSonic G Tablet
3. Asus Eee Pad Transformer Tablet
4. Motorola Xoom Tablet
The benchmark was performed by varying database sizes from 0.5 MB to
100 MB. The database had an index in one set of cases and had no
indexes in the other set of cases. Tests were done for quick and
options. The benchmark numeric results are given in Figure 2.
Figure 2: Benchmark Results for Empress checkAndRepair
Facility for Different Android Devices
Graphical presentation of the results for running the full
for different database sizes with indices and for different Android
devices is given in Figure 3.
Figure 3: Graph of the Benchmark Results for
Full Empress
checkAndRepair Facility for
Different Android Devices
Empress SDK for Android offers developers a number of useful options
to fine tune their applications for power down recovery situations.
Developers may selectively choose checkAndRepair
options depending on their application.
For example, if the database has only a few updatable tables (most
tables are read-only), there is no need to perform full checkAndRepair
since this operation rebuilds all user indices. In the case of
read-only tables there is an insignificant likelihood of damaging
their indexes. Developers can use a selective approach, and invoke checkAndRepair
operations for specific tables and only for certain types of repair
activity.
Empress SDK for Android also provides a verify option for developers
to check the state of database indices before they choose the option
to rebuild an index.
Instead of Summary
Empress SDK for Android can address the frustrations of many Android
developers when dealing with database inconsistency issues in the
Android environment. A rich facility of Empress
options gives plenty of useful, robust and efficient solutions to
build great database driven applications for the Android
environment.
Empress Software Inc.
www.empress.com
