Middleware Support for Time-Elastic Database Applications∗
António Casimiro
FCUL, Lisboa, Portugal
casim@di.fc.ul.pt
Marco Vieira
DEI-CISUC, Coimbra, Portugal
mvieira@dei.uc.pt
Henrique Madeira
DEI-CISUC, Coimbra, Portugal
henrique@dei.uc.pt
1. Introduction
2. Time-Elastic Applications
A database is a collection of data describing the activities
of one or more related organizations [3]. The software designed to assist in maintaining and using databases is called
database management system, or DBMS. A very important
notion in DBMS is the concept of transaction [2], which is
a set of commands that perform a given action and take the
database from a consistent state to another consistent state.
DBMS have a long tradition in high dependability, particularly in what concerns data integrity and availability aspects. However, and in spite of the importance of timeliness
properties in some applications domains, there are no mechanisms implemented in typical commercial DBMS able to
provide timeliness guarantees in the execution of transactions or at least to detect timing failures thereof.
The goal of TACID (Timely ACID transactions in
DBMS) [4] is to bring timeliness properties to the typical
ACID transactions, putting together classic database transactions and recent achievements in the field of real-time systems and distributed transactions. Three transaction classes
are considered in TACID: a) with no temporal requirements,
that is, normal ACID transactions; b) with strict temporal
requirements, meaning that the transaction has to be concluded within a specified time frame, otherwise the system
must detect the timing failure and take some action upon
it; c) with relaxed temporal requirements, meaning that a
time frame is specified and expected to be met with a given
probability, while the transaction will always execute.
In this fast abstract we address some work done in
the context of TACID, concerned with the development
of middleware support for the execution of relaxed timed
transactions. These transactions are particularly relevant
in database applications of a so-called time-elastic class,
which will dynamically select appropriate deadlines for
the executed transactions, following indications provided
by the middleware. The estimation of these deadlines is
based on probabilistic approaches, using temporal information collected from the execution of previous transactions.
The time-elastic class of applications includes those that
are able to adapt timing constraints during execution. In this
case, the collection of information about timing failures and
the temporal execution of transactions can be used to feed
a monitoring component or to tune specific application parameters in order to adapt its behavior to the actual load
conditions of the system. The application may decrease the
transaction submission rate, increase the transactions deadline if possible, or postpone the execution of transactions to
a latter time. Clearly, these applications can be based on
transactions with relaxed temporal requirements. Examples
of this class include databases that control mobile communication systems, where connection establishment can tolerate some delays (or may be refused) and billing transactions
can be postponed, or continuous manufacturing processes
such as chemical processes.
In these applications, the occurrence of timing failures
does not compromise the correctness of the database application. Typically, what is important is to secure that the
number of timing failures stays below a given bound, over
an interval of mission. In other words, what is important
to ensure is that a certain QoS is maintained, expressed in
terms of a timing bound to be secured with a given (usually
stable) coverage (probability that the timing failure does not
occur). Therefore, provided that the application is aware of
the actual coverage of the timing assumption, it may undertake one of the above-mentioned adaptation strategies, if
necessary, when this coverage changes.
∗ This work was partially supported by LaSIGE and by the FCT project
POSC/EIA/61568/2004 (TACID).
3. TACID Architecture
In a typical database environment the client application
communicates with the server through a database interface
layer (e.g., Oracle Call Interface). This layer is specific for
each DBMS and is responsible for managing all the communication with the database server. In order to enable the
provision of support for timed transactions, we add a wrapping layer, through which all the communications between
the client application and the database interface layer must
go by, which performs the necessary measurements and timing failure detection. Additionally, we also provide in this
layer the middleware support for time-elastic applications.
D B C lie n t
D B S e rv e r
C lie n t A p p lic a tio n
S Q L /R e s u lts
T F D /Q o S
in d ic a tio n
D B M S
M id d le w a r e S u p p o r t
M e a s u re m e n ts
T im in g F D
S Q L
N e tw o rk
D a ta b a s e In te rfa c e L a y e r
R e s u lts
Figure 1. Basic TACID architecture.
Figure 1 shows the basic architecture we propose for
adding middleware support in the client interface layer. The
application communicates with this layer using an interface
that supports the typical SQL requests and delivers the corresponding results. On the other hand, the interface also
provides indications about timing failures, sent in the form
of exceptions, and about changes in the QoS (the coverage of the assumed timing bound), by explicitly calling a
QoS handler of the application. In the wrapping layer, we
assume that there exist some mechanisms, or services, to
measure the duration of the transactions and to detect their
timing failures, such as those provided by a TCB [5].
4. Middleware Support Layer
The middleware to support time-elastic database applications has been developed in the Java language.
The programmer must create a class that extends the
TimeElastic class and define a handler to receive QoS
change indications.
Each transaction is defined by specifying its type (strict,
relaxed or ACID), a time interval (which is ignored for
ACID transactions), the query string and a unique identifier
(chosen by the programmer).
Another class, QoSCoverage, is provided to allow the
specification of QoS requirements and some parameters that
are necessary to control how and when indications about
QoS changes are sent to the application. An object of this
class can be associated to a transaction of the strict or relaxed types. It will monitor the execution times of its associated transaction and, based on probabilistic methods (as
described in [1]), it will be able to estimate the achievable coverage for a given time bound. When creating a
QoSCoverage object, it is necessary to define a timeliness bound and the (initially) required coverage for this
bound. During execution, when this object detects a sensible QoS change (the sensibility is also defined at object
creation time), it will call the application handler (which is
View publication stats
unique for the application), providing the identifier of the
transaction and a new time bound, or a new coverage, depending on the selected operation mode (also defined at creation time). It is up to the application programmer to decide
what to do with these new bounds.
A very simple example, illustrating the use of this middleware, is provided below.
public class TEAppExample extends TimeElastic{
public void handler(double val, String t_id,
boolean OperationMode){
// perform adaptation procedures
}
}
long timeout
double cov
double dev
int samples
=
=
=
=
50;
0.95;
5;
30;
//
//
//
//
50ms
coverage of 95%
sensibility of 5ms
for probabilistic analysis
TEAppExample tea = new TEAppExample();
TACIDTransaction trans = new TACIDTransaction(RELAXED,
timeout, "SELECT COUNT(*) FROM testtable", "id");
QoSCoverage qos = new QoSCoverage(trans.getTimeout(),
cov, dev, interval, MODE_TIME, 1);
TACIDConnection conn = new TACIDConnection(DBMSconn,
trans, TACIDConnection.CLIENT_SIDE);
tea.addTransaction(conn, qos);
TACIDResultSet res = null;
try{
res = tea.executeTransaction("id");
}catch(SQLException e1){
System.out.println("Unable to execute query!");
}catch(TACIDTimeoutException e2){
System.out.println("Transaction timed out");
if(tea.getTransactionType("id") ==
TACIDTransaction.RELAXED){
res = tea.getLastResults("id");
// Wait for transaction results
}
}
References
[1] A. Casimiro and P. Verı́ssimo. Using the Timely Computing
Base for Dependable QoS Adaptation. In Proceedings of the
20th IEEE Symposium on Reliable Distributed Systems, pages
208–217, New Orleans, USA, Oct. 2001.
[2] J. Gray and A. Reuter. Transaction Processing: Concepts and
Techniques. The Morgan Kaufmann Series in Data Management Systems. Jim Gray, 1993.
[3] R. Ramakrishnan. Database Management Systems. McGraw
Hill, second edition, 1999.
[4] TACID (Timely ACID Transactions in DBMS) web page.
http://gbd.dei.uc.pt/view project.php?id p=55.
[5] P. Verı́ssimo and A. Casimiro. The timely computing base
model and architecture. IEEE Transactions on Computers - Special Section on Asynchronous Real-Time Systems,
51(8):916–930, Aug. 2002.