application-tailored databases for real-time systems

Application-Tailored Databases for Real-Time Systems

Aleksandra Tesanovic

Philips Research Laboratories

Eindhoven, The Netherlands

E-mail: [email protected]

Jorgen Hansson

Software Engineering Institute

Carnegie Mellon University

Pittsburgh, PA, USA

E-mail: [email protected]

July 25, 2006

1 Introduction

The increasing number of real-time applications, and their intrinsic needs to manage larger amounts of

data, present the system designer with software architectural challenges at the time of the development and

through the system life-cycle. Real-time database research has successfully shown the merits of integrating

database support for dealing with data as a resource, because a data-centric view enables simpler capturing

of real-world data requirements, e.g., temporal validity, consistency, and quality, without losing semantics

under a strict task-centric approach. Each application imposes requirements on the architecture with respect

to the combination of memory consumption, processing capacity, hardware and operating system platform,

data quality requirements, workload arrival patterns, stringency and urgency of timeliness etc. These re-

1

2 DIMENSIONS OF TAILORABILITY 2

quirements imply that common support for dealing with real-time data efficiently needs to adhere to a

unique combination of requirements as it must be tailored for the application. The incentives for developing

a real-time database platform that can be specifically tailored to a range of application are: (i) economic

as software is reused and development time decreases, (ii) simplified maintainability as a common database

platform can be used across a family of real-time systems, and (iii) easier modeling of data requirements.

The purpose of this book chapter is twofold.

• We identify the challenges of application-specific databases regarding desirable tailoring capabilities

and their impact on the database architecture.

• We present the COMET database platform using which we show how tailorablity of the database

software architecture can be achieved by capitalizing on the benefits of component-based software

engineering and aspect-oriented methodology. We also demonstrate the types of analysis needed to

ensure that the resulting database configuration meets functional and non-functional requirements1.

The chapter is organized as follows. In section 2 we discuss distinct dimensions of real-time database

tailorability. Enabling technologies for tailorability and their impact to databases in general and the real-

time domain in particular are discussed in section 3. Section 4 gives a description of the COMET platform

and elaborates how COMET can be tailored. The chapter is concluded with a summary and directions for

future work in section 5.

2 Dimensions of Tailorability

A real-time database normally includes: (i) a physical storage of data items, (ii) a database schema, repre-

senting a way of structuring interrelated data items and their meta-data, and (iii) a database management

system (DBMS) that manages data items and ensures that, e.g., temporal validity, consistency, and quality

of data, is enforced. Hence, data items in a real-time system are stored on a physical storage according to

the database schema and are managed by the DBMS.

Characteristics of a real-time system using a database strongly influence characteristics of the database1Non-functional requirements are sometimes referred to as extra-functional requirements [7].


and, therefore, the dimensions of database tailorablity. Available storage medias in a real-time system dictate

the way data is going to be organized and interrelated on the media; hence, a database schema represents a

dimension of real-time database tailorability. The algorithms in the DBMS used for maintaining temporal

validity, consistency, and quality of data should be chosen to satisfy the requirements of the underlying real-

time system. These requirements, combined with the sparse memory and CPU resources, have a profound

impact on the architecture of a DBMS, which has to be flexible and susceptible to changes and evolution.

Moreover, as most embedded systems need to be able to run without human presence for long periods

of time, a database in such systems should have an architecture that facilitates software updates on-line

while maintaining a high degree of availability [27]. This yields in an essential dimension of the database

tailorability, namely tailorability of the database software architecture, i.e., DBMS.

In summary, we can observe that the characteristics of the applications using the database determine

desired database qualities and, therefore, produce the need for the tailoring of

• a database schema to meet the needs of the underlying hardware, and

• a database software architecture to meet diversity of functional and non-functional requirements placed

on a database system by an application, e.g., optimization of CPU usage and meeting memory and

timeliness requirements.

We illustrate dimensions of database tailorability in more detail on a typical example of an embedded

real-time application area, vehicle control systems, e.g., engine control and driver display control [11, 26].

Software controlling a vehicle typically consists of several distributed nodes called electronic control units

(ECUs), each implementing a specific functionality. Although nodes depend on each other and collaborate

to provide required behavior for the overall vehicle control system, each node can be viewed as a stand-alone

real-time system with specific data management characteristics. Therefore, the distinct functionality of a

node and its available memory determines the uniqueness of real-time databases used for data management

in the node.

The size of the nodes can vary significantly, from very small nodes to large nodes. For instance, a ve-

hicle control system could consist of a small number of resource adequate ECUs responsible for the overall

performance of the vehicle, e.g., 32-bit CPUs with a few Mb of RAM, and a large number of ECUs re-


sponsible for controlling specific subsystems in the vehicle, which are significantly resource-constrained, e.g.,

an 8-bit micro-controller and a few Kb of RAM [26]. In severely resource-constrained nodes, simple and

customized database schemas are preferable, while larger nodes allow more elaborate database schemas to

be implemented. In safety-critical nodes, tasks are often non-preemptive and scheduled off-line, avoiding

concurrency by allowing only one task to be active at any given time. This, in turn, influences functionality

of a database in a given node with respect to concurrency control. Less critical and larger nodes having pre-

emptable tasks would require concurrency control mechanisms and support for database queries formulated

during run-time.

One can optimize CPU usage in a node by adding so-called on-demand algorithms that dynamically

adjust the update frequencies of data based on how rapidly sensor values change in the environment. On-

demand algorithms ensures that data is updated only when it is no longer fresh [11] (this is in contrast

to approaches [18, 20, 47, 13] where sensor values are always updated when data is assumed to become

obsolete at the end of a constant time period, representing the worst case). As the system evolves, more

elaborate schemes for data management may be applicable [25]. Namely, adding active behavior to the

system in terms of event-condition-action (ECA) rules is essential to embedded applications that are time-

triggered but require actions on data to be performed even when a certain event occurs, e.g., when the engine

overheats appropriate updates on data items should be triggered to ensure cooling down. Each rule in the

ECA paradigm reacts to certain events, evaluates a condition, and based on the truth value of the condition,

may carry out an action [2].

Additionally, the trend in the vehicular industry is to incorporate quality of service (QoS) guarantees in

the new generation of vehicle control systems [25, 33], implying that certain nodes are enhanced with various

QoS management requirements. Typically, one is interested in controlling the performance, e.g., utilization,

of a real-time database systems using the metric deadline miss ratio [22], which gives the ratio of tasks that

have missed their deadlines. This can be achieved by using a feedback-based QoS management method

referred to as FC-M [22], where deadline miss ratio is controlled by modifying the admitted load. Another

way to change the requested utilization is to apply the policy used in QMF [15], where the quality of data

in real-time databases is manipulated to achieve the desired deadline miss ratio.

3 TAILORABLE REAL-TIME AND EMBEDDED DATABASE SYSTEMS 5

We can conclude that in order to provide support for data management in embedded and real-time

systems controlling a vehicle, it is necessary to ensure that database functionality can be tailored both on

the level of DBMS functionality and on the level of database schemas. The DBMS functionality should be

tailored to suit the needs of each node with respect to memory consumption, concurrency control, recovery,

scheduling techniques, transaction models, QoS requirements, and storage models. Also, the architecture of

a DBMS should be flexible and allow modifications and adding new functionality to the system as it evolves.

3 Tailorable Real-Time and Embedded Database Systems

As we already identified, enabling tailorability of a real-time database for a specific application or family

of applications has potential. In this section we investigate tailorability of existing real-time and embedded

database systems. We then present representative software engineering techniques developed specifically to

facilitate configuration and reuse of general purpose software. Finally, we inspect how these techniques have

been applied to the area of database systems, building up the knowledge base that enables us to identify

concrete challenges in tailoring a database system for resource-constrained real-time applications.

3.1 Existing Real-Time and Embedded Database Systems

A significant amount of research in real-time databases has been done in the past years, resulting in real-time

database platforms such as ART-RTDB [17], BeeHive [35], DeeDS [1] and RODAIN [21]. The effort when

developing databases was primarily focused on various schemes for concurrency control, transaction schedul-

ing, active behavior, logging and recovery, and less on configurability of database software. Hence, these

database are designed and developed with desired functionality for a specific application; their monolithic

structure makes them intrinsically hard to modify or extend with new required functionality. Also it is not

possible to reuse a (part of a) database in a different real-time application. Additionally the majority of

mentioned real-time platforms was developed with the assumption that there is no tradeoff between desired

database functionality and available resources, i.e., that there are no constraints on available memory or

CPU. In embedded environments, however, resources such as memory and CPU are sparse and a real-time

database used in such an environment needs to be developed carefully in order to use the available resources


efficiently. Trading off functionality to gain resources is one of the main concerns addressed by the embedded

databases on the market, e.g., Polyhedra [31], RDM and Velocis [23], Pervasive.SQL [30], Berkeley DB [3],

and TimesTen [44]. However, similar to the research platforms mentioned, all these embedded databases

have different characteristics and are designed with a specific application in mind. They support different

data models, e.g., relational vs. object-relational model, and different operating system platforms [39]. More-

over, they have different memory requirements and provide various types of interfaces for users to access

data in the database. Application developers must carefully choose the embedded database their application

requires, and find the balance between required and offered database functionality.

Given the traits of existing real-time and embedded databases, system designers are faced with a difficult,

time-consuming, and costly process when choosing and adapting an existing database for their applications.

3.2 Enabling Tailorability with Components and Aspect

The focus in software engineering research community in the past decade was on techniques that enable

development of software quickly, with low development costs and high degree of tailorability. Component-

based software development (CBSD) has proved to be efficient for development of complex software systems

from a pre-defined set of components explicitly developed for reuse [36]. CBSD postulates that software

systems can be developed rapidly and tailored explicitly for a specific application or a product by choosing

appropriate components from the component library and composing them into a resulting software system,

i.e., a configuration or an assembly. Often, a system configuration can be viewed as one composite component,

which can be (re)used in a larger system, e.g., a database system might consist of a number of components,

but when used in a real-time application could be viewed as a constituting component of that application.

Components communicate with its environment through well-defined interfaces, e.g., interfaces in COM

and CORBA are defined in an interface definition language (IDL), Microsoft IDL and CORBA IDL, respec-

tively. In an interface, a collection of operations implemented in a component is normally listed together with

the descriptions and the protocols of these operations [7]. Components are often defined with more than one

interface. For example, a component may have three types of interfaces: provided, required, and configura-

tion interfaces [4]. Provided and required interfaces are intended for the interaction with other components,


whereas configuration interfaces are intended for use by the user of the component, i.e., a software engineer

(developer) who is constructing a system using reusable components. Having well-defined interfaces ensures

that an implementation part of a component can be replaced in the system without changing the interface.

Even though CBSD offers modularity, reusability, and configurability of software in terms of components,

many features of software systems, e.g., synchronization, memory optimization, and temporal attributes,

crosscut the overall system and thereby cannot be encapsulated in a component with a well-defined inter-

face. Aspect-oriented software development (AOSD) [16] has emerged as a technology that provides an

efficient way of modularizing crosscutting concerns in software systems. AOSD ensures encapsulation of

system’s crosscutting concerns in “modules”, called aspects. Aspects are written in an aspect language that

corresponds to the language in which the software system is written, e.g., AspectC [6] for software written

in C, AspectC++ [34] for C++ or C, and AspectJ [46] for Java-based software.2

Aspects can be developed independently of the software and added to the system in a process called

aspect weaving. Aspect weaving is done using join points of the software for which the aspect is written.

A join point is a point in the code of the program where aspects should be weaved, e.g., a method, a type

(struct or union). A declaration in an aspect used to specify code that should run when the join points are

reached is referred to as an advice. Different types of advices can be declared, as follows:

• before advice, which is executed before the join point,

• after advice, which is executed immediately after the join point, and

• around advice, which is executed instead of the join point.

A special type of an advice, called inter-type advice or an introduction can be used for adding members to

the structures or classes.

3.3 Component-Based and Aspect-Oriented Database Systems

SADES [32], a semi-autonomous database evolution system is an example of general-purpose object-oriented

database systems where customizations of database schema are done using AOSD. In SADES, database2All existing aspect languages are conceptually very similar to AspectJ.


schema can be modified by applying aspects that (i) change links among entities, e.g., predecessor/successor

links between object versions or class versions, inheritance links between classes, etc., (ii) change the version

strategy for object and class versioning, and (iv) extend the system with new meta-classes.

When it comes to tailorability in DBMS dimension, there is a number of general-purpose databases where

database functionality can be extended or tailored by means of components. For example, Oracle8i [29],

Informix Universal Server with its DataBlade technology [14], Sybase Adaptive Server [28], and DB2 Univer-

sal Database [5] are extendable databases that can be augmented with non-standard functionality. Namely,

each of the database is a fully functional DBMSs that implements all standard DBMS functionality [8].

Non-standard features and functionality not yet supported, e.g., abstract data types or implementations of

new index structures, can be plugged into a pre-defined plug-ins in the DBMS architecture. OLE DB [24] is

an example of a database that integrates existing data stores into a database system and provide users and

applications with a uniform view of the entire system. In this model the architecture introduces a common

intermediate format into which local data formats can be translated. Components, also known as wrappers,

are located between the DBMS and each data source. Each component mediates between the data source

and the DBMS, i.e., it wraps the data source. KIDS [9] is an example of databases that enable composition

of non-standard DBMSs out of reusable components.

While the mentioned database system are tailorable they do not provide support for enforcing real-time

behavior nor do they scale down to a size and functionality acceptable in resource-constrained systems.

3.4 Challenges

When developing tailorable databases for resource-constrained real-time systems a number of challenges

arises. Firstly, based on the application domain the focal dimensions of tailorability should be determined.

We found that in most real-time applications it is more important to ensure flexibility in the real-time

database architecture and provide variability of data management algorithms that optimize resource usage,

than enabling tailoring of database schema.

Further, to achieve fast and cost-effective development of database systems for specific real-time appli-

cation or families of applications, one should apply appropriate software development technology. Given

4 THE COMET APPROACH 9

that CBSD and AOSD have been developed to address complementary concerns in software design and

development, it follows intuitively that combining the two in development of software systems could further

improve configurability of software while keeping the costs of development and time to produce the software

low. We have explored the combination of the two techniques in real-time system development within the

ACCORD3 framework [43] and demonstrated the benefits of combining the techniques in this domain. In

the next sections, we demonstrate the benefits of the combination of two approaches in development of a

tailorable embedded real-time database platform, COMET.

Note that, if a real-time system is developed using reusable artifacts, then ensuring that the database

configuration satisfies functional and and non-functional requirements is essential. Meeting non-functional

requirements in terms of available memory footprint and timeliness, e.g., determining allowed worst-case

execution times (WCETs) of transactions such that deadlines can be met, are especially interesting for the

real-time and embedded domain. Therefore, together with technology for tailoring the database, providing

accompanied analysis methods and tools is necessary.

4 The COMET approach

COMET is a real-time embedded database platform that can be tailored to fit the needs of various real-time

and embedded applications. In the remainder of this section we present the relevant details of the RTCOM

model and aspect packages as these are main facilitators of COMET tailorability. We then elaborate how

COMET can be tailored for various applications by adding new features via aspect packages.

4.1 Components and Aspects

Tailorability in COMET refers primarily to tailorability of its software architecture, which is achieved by

defining two basic building and reusable units of the architecture, components and aspect packages.

Components implement a part of a well-defined database functionality and exhibit strong internal cohe-

sion but loose coupling with other parts of database functionality. Components are designed and implemented3ACCORD stands for aspectual component-based real-time system development [43].


Providedfunctionalinterface

Requiredfunctionalinterface

Composition interface(declared join points)

RTCOM

Figure 1.1: RTCOM in a nutshell

using a real-time component model (RTCOM) [43] and can be tailored by aspect weaving.

RTCOM defines how a component in a real-time environment should be designed and implemented such

that tailoring of components for specific needs of an application can be done while preserving information

hiding and enabling component reuse and analysis of the system’s temporal behavior, e.g., WCET analysis or

formal verification using timed automata [40, 38]. RTCOM components are “grey” as they are encapsulated

in interfaces, but changes to their behavior can be performed in a predictable way using aspects. Hence,

components provide certain initial functionality that can be modified or changed by weaving of aspects. Each

RTCOM component has two types of functional interfaces: provided and required (see figure 1.1). Provided

interfaces reflect a set of operations that a component provides to other components, while required interfaces

reflect a set of operations that the component requires (uses) from other components. The composition

interface declares join points where changes can be made in the component functionality and thereby defines

places in the component where modifications can be done. Join points need to be explicitly declared in

a separate interface to ensure evolution the system. Namely, when developing new aspects, the aspect

developer does not necessarily have to have full knowledge of the component code to develop aspects that

would tailor that component quickly and successfully.

A composition of COMET components providing the basic functionality we denote as basic COMET

configuration (or simply basic COMET). We refer to a minimal subset of database functionality that can

constitute a working database as the basic database functionality. The minimal subset of functionality

typically implies having an interface for applications to access the database and functionality for defining

and executing transactions that read and update data on a physical storage. Hence, we developed the


following COMET components constituting basic COMET:

• user interface component (UIC),

• scheduling manager component (SMC),

• indexing manager component (IMC),

• transaction manager component (TMC), and

• memory manager component (MMC).

The UIC provides a database interface to the application, which enables a user (i.e., an application using

the database) to query and manipulate data elements. User requests are parsed by the user interface and

are then converted into an execution plan. The TMC is responsible for executing incoming execution plans,

thereby performing the actual manipulation of data. The IMC is responsible for maintaining an index of

all tuples in the database. The SMC keeps records of transactions that exist in the system. Note that in

the basic configuration of COMET we have a basic data model and a basic transaction model. The basic

data model contains meta-data used for concurrency control algorithms in databases. The basic transaction

model characterizes each transaction τi only with a period pi and a relative deadline di. The basic COMET

is especially suitable for small embedded vehicular systems [43].

Aspect packages implement a new, non-basic, functionality that can be added to the existing database

functionality and thereby create a new variant of the database system. All non-basic functionality is consid-

ered to be a feature of the database. The features in the real-time database domain typically are real-time

policies facilitating concurrent access to the database, various indexing strategies, enabling active behav-

ior, providing QoS guarantees, etc. The creation of database configurations with new feature(s) is done

by adding the appropriate aspect package(s) to the basic COMET. Hence, an aspect package represents a

way of packaging the specification and implementation of real-time features, e.g., concurrency control, QoS,

indexing, and scheduling, for reuse and configuration.

At an abstract level, an aspect package represents a way of specifying a real-time database feature, where

a database feature is specified independently of an application by means of aspects and components. At a


C4

C5

Code of thetailored component

Componentimplementation

(without aspects)

Aspect woveninto component

A1 A2

C1 C2 C3Basic configuration consisting of

tailorable components

Feature implemented by an aspectpackage (consisting of aspects A1-

A2 and component C5)1

A3 A4C6A5

Newconfigurationaugmented

with newfunctionality

Figure 1.2: Creating a family of databases using aspect packages

concrete level, an aspect package consists of a set of aspects and (possibly empty) set of components imple-

menting a variety of real-time policies. Components from the aspect package contain the main functional

infrastructure of the features (policies), e.g., QoS management algorithms. In addition, there are three types

of aspects defined in an aspect package as follows.

• Policy aspects adapt the system to provide a variety of related real-time policies, e.g., feedback-based

QoS policies or concurrency control policies.

• Transaction model aspects adapt the transaction model of a real-time database system to the model

used by the policies by adding various attributes to transactions, e.g., a utilization transaction model

needs to be used for a feedback-based QoS policy where utilization of the system is controlled.

• Connector aspects facilitate composition of an existing system with the components from the aspect

package.

Using an aspect package a system designer can develop several applications with similar characteristics with

respect to a certain real-time policy as illustrated in figure 1.2. Therefore, each family of applications would

have its unique aspect package.

We developed the following COMET aspect packages.

• The concurrency control aspect package represents an implementation of a set of concurrency control

policies that enables producing a family of databases with distinct policies on handling data conflicts.

The concurrency control aspect package consists of one component, the locking manager component


(LCM), and aspects implementing high priority two-phase locking (HP-2PL) and optimistic divergence

control (ODC) protocols.

• The index aspect package represents an implementation of indexing policies that facilitate efficient

data access. The index aspect package consists of one component, an alternative IMC that implements

B-tree structure (IMC B-tree), and the aspect implementing GUARD indexing policy.

• The active behavior package enables creating database system configurations capable of reacting on

aperiodic events. It consists of aspects implementing on-demand algorithms and ECA rules.

• The QoS aspect package gives a set of components and aspects that implement a variety of feedback-

based QoS policies. The QoS aspect package consists of two components, the quality of service QoS

admission controller component (QAC) and the feedback controller component (FCC), and the aspects

implementing a number of feedback control-based quality of service policies.

Note that, even though the content of an aspect package varies depending on the functionality provided

within the package, each package typically has one or a number of aspects that implement a specific set of

(related) policies. Additionally, if a policy requires changes in the transaction model of COMET, the package

contains appropriate aspects augmenting this model. To illustrate how the transaction and data model need

to be adapted to the policy used, consider the FC-M and QMF QoS algorithms. These algorithms require

more complex data and transaction models that can capture additional meta-data such as mean inter-arrival

and execution times. Both FC-M and QMF require a transaction model where transaction τi is classified as

either an update or a user transaction. Update transactions arrive periodically and may only write to base

(temporal) data objects. User transactions arrive aperiodically and may read temporal and read/write non-

temporal data. In this model, denoted the utilization transaction model, each transaction has the following

characteristics:

• period pi (update transactions),

• estimated mean inter-arrival time rE,i (user transactions),

• actual mean inter-arrival time rA,i (user transactions),


Attribute Periodic Transactions Aperiodic Transactions

di di = pi di = rA,i

uE,i uE,i = xE,i/pi uE,i = xE,i/rE,i

uA,i uA,i = xA,i/pi uA,i = xA,i/rA,i

Table 1.1: The utilization transaction model

• estimated execution time xE,i,

• actual execution time xA,i,

• relative deadline di,

• estimated utilization4 uE,i, and

• actual utilization uA,i.

Table 1.1 presents the complete utilization transaction model. Upon arrival, a transaction presents the

estimated average utilization uE,i and the relative deadline di to the system. The actual utilization of the

transaction uA,i is not known in advance due to variations in the execution time.

4.2 COMET Configurations

A significant number of COMET configurations fulfilling distinct requirements can be made from existing

COMET components and aspects. In this section we describe a subset of possible COMET configurations,

their relationship, and constituents.

The basic configuration consists of five COMET components (see table 1.2): UIC, SMC, TMC, IMC,

and MMC. As mentioned, the configuration uses the basic transaction model, and it is especially suitable

for small resource-constrained embedded vehicular systems [25]. All remaining database configurations are

built upon the basic COMET configuration by adding appropriate aspects and components from available

aspect packages.4Utilization is also referred to as load.


The high priority two-phase locking concurrency control configuration (COMET HP-2PL)

includes all basic components, as well as the LMC and the HP-2PL aspect from the concurrency control

aspect package. This configuration is suitable for more complex real-time systems where transactions can

execute concurrently and conflict resolution can be done by employing pessimistic concurrency control.

The optimistic divergence control configuration (COMET ODC) is built on top of the basic

COMET configuration by adding the following constituents of the concurrency control aspect package: the

LMC, the ODC aspect, and the epsilon-based transaction model aspect, as indicated in table 1.2. This

configuration, therefore, enables database system to resolve conflicts based on the ODC policy. ODC [45]

is based on an optimistic concurrency control method introduced by Wu and Dias [48] that uses weak and

strong locks and assumes transaction execution in three phases: read, write, and validation phase. As

such, COMET ODC is suitable for soft real-time applications having concurrent transactions where conflict

resolution can be postponed until validation phase of the transaction.

The GUARD-link configuration (COMET GUARD) requires all components from the basic COMET

configuration, except the IMC. It also requires the constituents of the concurrency control aspect package.

Furthermore, from the index aspect package the IMC B-tree and the GUARD link policy aspect are re-

quired. Haritsa and Seshadri [12] proposed the GUARD-link indexing protocol to further strengthen the

index management of a soft real-time system by taking into account transaction deadlines, which we adopted

in COMET as a part of the index aspect package. Two distinct COMET GUARD configurations can be

made, depending on the choice of the concurrency control policy from the concurrency control aspect package.

Namely, if the HP-2PL with similarity aspect is used, COMET GUARD with HP-2PL is created. If ODC is

used, the configuration of COMET GUARD with ODC is made (see table 1.2). COMET GUARD configu-

rations are desirable in soft real-time applications where indexing structure should be further optimized in

terms of meeting transaction deadlines.

A number of COMET QoS configurations can be made using the COMET QoS aspect package together

with different combinations of aspects and components from the concurrency control aspect package and the

index aspect package. For simplicity here we discuss only COMET QoS configurations that are distinct with


Concurrency controlaspect package

Policyaspects

Transactionmodel aspects

Connectoraspects

Components LMC

ODC

HP-2PL

Epsilon-based

COMET configurations

COMET

HP-2PL

COMET

ODC

X

X

X

COMETGUARD

X

XXX

with H

P-2PL

with O

DC

ConcurrentCOMET

X

X

X

Index aspect package

Policyaspects

Transactionmodelaspects

Connectoraspects

Components IMC_B-tree

GUARD link

X

X

MMC X

Basic

COMET

IMC

SMC

TMC

UIC

BasicCOMET

components

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

COMET HP-2PL - The high-priority 2 phase locking configurationCOMET ODC- The optimistic divergence control configuration

LEGENDX in the table means that an aspect/component is part of a configuration

UIC - user interface componentTMC - transaction manager component

IMC - index manager componentMMC - memory manager component

LMC - locking manager componentSMC - scheduling manager component

Table 1.2: Relationship between different parts of the concurrency control and the index aspect package and

various COMET configurations


LMC MMC

QAC

FCCC

A Actuator composition

Utilization Model

MissedDeadlineController

Missed Deadline

MonitorDifferentiation Model

SchedulingStrategy

Data Access Control

Self Tuning Regulator

Code of thereconfiguredcomponent

Base componentimplementation

(without aspects)

Aspect woveninto component

A A

C

UIC SMC TMC IMC Concurrentconfiguration

Admission controlconfiguration

FC-Mconfiguration

QMFconfiguration

STRconfiguration

C Controller composition

Transaction model aspects

Composition aspects

Policy aspects

LEGEND

User InterfaceComponent

(UIC)

SchedulingManager

Component(SMC)

TransactionManager

Component(TMC)

IndexManager

Component(IMC)

LockingManager

Component(LMC)

MemoryManager

Component(MMC)

QoS ActuatorComponent

(QAC)

FeedbackController

Component(FCC)

Configurationboundary

Config 1

Config 2

Config 2 refines Config 1by adding the aspect to

the component

UM UM

UM

DM

DM DM

MDM

MDM

MDC

MDC MDC

SS

SSSSSS

DAC DAC DAC DAC

DAC

STR STR STR STR

STR

Figure 1.3: Creating a family of real-time systems from the COMET QoS aspect package

respect to QoS-related aspect and components. Any of the concurrent or GUARD COMET configurations

from table 1.2 can be used as a foundation for adding aspects and components from the COMET QoS aspect

package, and creating a COMET QoS configuration. Hence, we discuss in detail five distinct COMET QoS

configurations that provide admission control, FC-M, QMF, self-tuning, and least squares regression QoS.

However, note that depending on the chosen aspects and components from the COMET QoS aspect package,

the number of possible configurations in COMET QoS family is higher (see figure 1.3). Table 1.3 illustrates

the elements of the QoS aspect package used in the five representative COMET QoS configurations.

The admission control QoS configuration includes one component from the QoS aspect package, the

QAC. The configuration also requires two aspects, the QAC connector aspect and the utilization transaction

model aspect. The QAC connector aspect adds the QAC to the existing controlled system, while the

utilization transaction model aspect extends the transaction model (see table 1.3). The admission control

configuration is simple as it only provides facilities for admission control.


QoS aspect package

Policyaspects

Transactionmodel aspects

Connectoraspects

Utilization transaction model

Controller connector

Actuator connector

Actuator utilization policy

Missed deadline monitor

Missed deadline controller

Data differentiation

Scheduling strategy

Data access monitor

QoS through updatescheduling

COMET configurations

Admission

contro

lCOMET

FC-M COMET

QMF

X

X

XX

X

X

X

XX

X

X

X

X

X

X

X

X X X

ComponentsQAC

FCC

X

X

X

X

X

Self-tuning regulator

Adaptive regressionmodel

COMET

STR COMET

RM

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X X

COMET FC-M - The miss ratio feedback configurationCOMET QMF - The update scheduling configuration

COMET STR - The self-tuning regulator configuration

COMET RM - The regression model configuration

LEGEND

X in the table means that an aspect (or a component) is part of a configuration

QAC - QoS Actuator Component FCC - Feedback Controller Component

Table 1.3: Relationship between different parts of the QoS package and various COMET QoS configurations


The miss ratio feedback configuration (COMET FC-M) provides QoS guarantees based on the

FC-M policy. The configuration includes the QAC and FCC components and their corresponding connector

aspects, the utilization transaction model aspect, the missed deadline monitor aspect, and the missed deadline

controller aspect (see table 1.3). These aspects modify the policy of the SMC and FCC to ensure that QoS

with respect to controlling the number of deadline misses is satisfied in soft real-time systems where workload

characteristics are generally unpredictable.

The update scheduling configuration (COMET QMF) provides the QoS guarantees based on the

QMF policy. Here the data differentiation aspect and scheduling strategy aspect are used to enrich the

transaction model. Moreover, the data access monitor aspect is required to ensure the metric used in QMF.

Also, the QoS through update scheduling aspect is used to further adjust the policy of QAC to suit the QMF

algorithm. COMET QMF is especially suitable for soft real-time applications where maintaining a certain

level of data quality is of interest.

The self-tuning regulator configuration (COMET STR) provides adaptive QoS control where the

control algorithm parameters are adjusted by using the self-tuning regulator. This aspect is added to the

aspects and component constituting the COMET FC-M configuration to ensure the adaptability of the

control already provided by the COMET FC-M configuration. The COMET STR configuration can be used

for real-time systems that cannot be modeled as time-invariant.

The regression model configuration (COMET RM) provides adaptive QoS control where the control

algorithm parameters are adjusted by using the least square technique and the regression model. This aspect

also requires all the aspects needed for the FC-M configuration to ensure adaptability of QoS management.

Note that the process of adding aspect packages to the basic COMET configuration is incremental. That is,

when making QoS COMET configuration, first the concurrency control aspect package should be applied on

the basic configuration, and then appropriate index package (optional), and only then aspects and component

from QoS aspect package can be applied to configure COMET QoS configuration.


4.3 Automated Configuration and Analysis

We developed a number of analysis techniques that can be used to check if the obtained COMET configuration

is suitable for the underlying real-time environment.

We embodied these techniques into ACCORD modeling environment (ACCORD-ME) tool suite, which

supports both configuration and analysis. ACCORD-ME is a constituting part of the tool-set called AC-

CORD tool development environment. The overall ACCORD tool environment is developed to provide

support for development, analysis and deployment of reconfigurable real-time systems [37].5

ACCORD-ME is a model-based tool, implemented using the generic modeling environment (GME), a

toolkit for creating domain-specific modeling environments [10]. In general, the creation of a GME-based

tool is accomplished by defining meta-models that specify the modeling paradigm (modeling language) of

the application domain. In our case, based on the content of the aspect packages, modeling paradigms are

defined for ACCORD-ME. The aspect package modeling paradigms are given as UML diagrams and they

define the relationship between components and aspects in the package, their possible relationship to other

components of COMET, and possibilities of combining components and aspects into different configurations.

The GME environment also enables specifying multiple tool plug-ins, which can be developed indepen-

dently of the environment and then integrated with the GME to be used for different modeling and/or

analysis purposes. Exploiting this, ACCORD-ME is developed with a number of sub-tools, namely the

configurator, memory and worst-case execution time (M&W) analyzer, and formal verifier (see Figure 1.4).

An Example

We use the following example to illustrates how COMET can be tailored for a particular real-time application

using existing aspects and components and analyzed to ensure that it meets functional and non-functional

requirements. We focus here on using ACCORD-ME for configuring COMET for a specific ECU in vehicles,

which is a new generation of ECUs used for controlling the engine in a vehicle, and it has the following set

of data management requirements.5The name ACCORD-ME originates from the name of the approach for aspectual component-based real-time system

development (ACCORD) [42] for which this tool was initially developed.


R1: The application performs computations using data obtained from sensors and forwards the computation

results directly to actuators; recall that sensor data items are typically referred to as base data items.

R2: Sensor data should reflect the state of the controlled environment implying that transactions used for

updating data items should be associated with real-time properties, such as periods and deadlines.

R3: Values of data should be updated only if they are stale6 to save computation time of the CPU.

R4: Multiple tasks can execute concurrently in an ECU, and operate on the same data. Hence, consistency

needs to be enforced.

R5: The tasks in the ECU should be scheduled according to priorities.

R6: The memory footprint of the system should be within the memBound, which can be obtained from the

ECU specifications.

When configuring COMET the ECU we start by specifying the requirements using the configurator tool

in ACCORD-ME (see figure 1.4). The configurator provides three levels of support, expert, configuration,

and requirement-based, based on the expertise and preferences of the developer. The expert option is used by

developers familiar with the content of the aspect packages and all of its provided functionality and policies.

The configuration-based option gives a list of possible configurations of the system that can be created from

the aspect packages. The requirement-based option provides the system developer with a list of possible

requirements from which the developer can choose a relevant subset suitable for a particular application.

Thus, developers do not need to know the contents of the aspect packages to be able to configure QoS

management.

Given that we know the system requirements, then the requirement-based option in the configurator can

be used to guide the system composition. Now, based on the requirements R1-R5 we can choose options

in the requirement-based form (shown in figure 1.5) as follows. The configuration of the COMET database

suitable for the ECU contains base data items. Since tasks using the base data are not storing intermediate

results, there is no need for storing derived data (R1). Furthermore, the database should provide mechanisms

for dealing with concurrency such that conflicts on data items are resolved (R4) and data items that are6A data item is stale if its value does not reflect the current state of the environment.


AnalyzerConfigurator

W&M Analyzer

AspectAspectAspectAspect

ComponentComponentComponentComponent

Library Library Library Library

contentcontentcontentcontent

ConnectionConnectionConnectionConnection

Figure 1.4: The editing window of ACCORD-ME, which is a part of the ACCORD Development Environment


Figure 1.5: Requirement-based configuration of the real-time database system


stale are updated (R3). This can be achieved using HP-2PL with similarity [19]. The transaction model

should be chosen such that transactions are associated with periods and deadlines (R2). We choose the

RMS scheduling policy to enforce priority-based scheduling of tasks (R5), performance guarantees in terms

of levels of QoS are not required.

When these decisions are submitted, the configurator loads the relevant components and aspects into

the ACCORD-ME editing area, where the designer can assemble the system by connecting the components

and aspects, as shown in Figure 1.4. Each aspect and component contains information stating with which

components it can be connected to form a functionally correct COMET configuration. Hence, the configu-

rator aids in obtaining a configuration of a system that satisfies specific needs of the application and that

is functionally correctly assembled. The configuration, i.e., components, aspects, and their relationships, is

stored in an XML file. A system configuration satisfying functional requirements R1-R5 is shown in the

upper part of figure 1.6 (denoted as step 1 in the figure). Note that in ACCORD-ME ovals are used as the

graphical representation of aspects, while squares represent components.

The obtained configuration can be analyzed by other sub-tools available in ACCORD-ME, namely M&W

analyzer and formal verifier. Specifically, formal analysis can be performed to ensure that adding constituents

of the aspect packages preserves already proven properties of the original system [38], thereby ensuring that

functionality of the original system is preserved or modified in a well-understood way. For the purposes of

formal analysis, a COMET configuration is transformed from a UML-based model to a timed automata-based

model.

When the composition of the system is made, it should be analyzed to determine the memory needs of

the configuration and contrast these to the available memory in the ECU. Hence, when the configuration

part of the system development is finished then the obtained configuration can be analyzed using the M&W

analyzer tool plug-in that analyzes a configuration with respect to WCET and memory requirements using

the aspect-level WCET analysis we developed earlier [40, 41]. It takes as input: an XML configuration file

produced by the configurator and run-time properties of components and aspects. Run-time properties are

also expressed in XML and contain the run-time information needed by the tool in order to calculate the

impact of aspect weaving and system composition with respect to WCET or static memory consumption.


Figure 1.6: The snapshot of ACCORD-ME when doing analysis on a real-time system configuration


WCETs needs are expressed in terms of symbolic expressions. Hence, they are a function of one or several

parameters that abstract the properties of the underlying run-time environment. The symbolic expressions

need to be re-evaluated for each run-time environment, i.e., parameters in symbolic expressions should be

instantiated in the analysis. Hence, the M&W analyzer provides a list of symbolic expressions and the list of

necessary parameters that need to be configured. Since it is possible to assemble a number of configurations

in ACCORD-ME, e.g., when using the expert option, the M&W analyzer detects the configurations and

enables developers to choose which configuration she/he would like to analyze. Moreover, it is possible to

choose whether WCET or memory analysis of the system should be performed.

Figure 1.6 is the snapshot of the analysis process. When the M&W analyzer is invoked, it detects

the configuration(s) one might have made in ACCORD-ME and prompts for the choice of a configuration.

In our example, we created only one configuration and denoted it PessimisticConcurrecyControl. This

configuration is detected by the M&W analyzer, as illustrated by step 2 in figure 1.6. After the configuration

is chosen, the appropriate files describing run-time aspects of components and aspects are loaded for analysis.

Since run-time properties of aspects and components are described in terms of symbolic expressions with

parameters, the values of these parameters are instantiated during analysis, and the list of components that

require instantiation of parameters is displayed during analysis (step 3 in the figure). One can also make

an inspection of the symbolic expressions and input the values of parameters in the expressions, as depicted

by step 4. Note that advices that modify components are included in the component run-time description

as shown in step 5. Once the values of parameters are set for this particular ECU, the tool outputs the

resulting WCET and/or memory consumption values which can be compared with the values given in the

memory requirement (R6).

If the obtained configuration satisfies the requirements of the target ECU, the next step is to compile

the system and deploy it into the run-time environment, which is done using the configuration compiler. As

mentioned previously, the configuration compiler also provides documentation of the composed configuration

of COMET.

5 SUMMARY 27

5 Summary

There is a clear need for enabling development of real-time database systems that can be tailored to meet

specific application needs. In this chapter we have analyzed real-time application characteristics and identi-

fied those that have the greatest impact the database functional and non-functional requirements. We have

shown that available hardware dictates the organization of database schema yielding the need for tailorabil-

ity of the database. Furthermore, software architecture of the real-time and embedded databases should be

tailorable to facilitate cost-effective and fast development of families of database systems.

We have illustrated how tailorability of the database software architecture can be achieved on the example

of the COMET database system. In COMET, the flexibility and extendability of the architecture is achieved

by the means of components and aspects, and depending on the application requirements, the designer takes

appropriate components and aspect from the COMET library and forms the COMET configuration. Over

thirty database configuration with distinct characteristics can be developed using artifacts from the COMET

library. The designer is aided in the tailoring and analysis process by appropriate tools.

Based on our experience, we believe that the proposed technologies for facilitating tailorabiltiy into the

real-time domain enable us to more quickly develop functionally correct application-specific database systems

that meet non-functional constraints, e.g., small memory footprint, adequate worst-case execution times that

ensure meeting deadlines, and improved CPU performance.

Acknowledgments

The authors would like to thank Jack Goossen and Rob van Ommering for the initial reviewing of the

manuscript. This work was financially supported by the Swedish Foundation for Strategic Research (SSF)

via the SAVE project and the Center for Industrial Information Technology (CENIIT) under contract 01.07.

References

[1] S. F. Andler, J. Hansson, J. Eriksson, J. Mellin, M. Berndtsson, and N. Eftring. DeeDS towards a

distributed and active real-time database system. ACM SIGMOD Record, 25(1), 1996.

REFERENCES 28

[2] P. Atzeni, S. Ceri, S. Paraboschi, and R. Torlone. Database Systems: Concepts, Lanuages and Archi-

tectures. McGraw-Hill, 1999. Chapter Active Databases.

[3] Berkeley DB. Sleepycat Software Inc., http://www.sleepycat.com, March 2003.

[4] J. Bosch. Design and Use of Software Architectures. ACM Press in collaboration with Addison-Wesley,

2000.

[5] M. J. Carey, L. M. Haas, J. Kleewein, and B. Reinwald. Data access interoperability in the IBM database

family. IEEE Quarterly Bulletin on Data Engineering; Special Issue on Interoperability, 21(3):4–11,

1998.

[6] Y. Coady, G. Kiczales, M. Feeley, and G. Smolyn. Using AspectC to improve the modularity of path-

specific customization in operating system code. In Proceedings of the Joint European Software Engi-

neering Conference (ESEC) and 9th ACM SIGSOFT International Symposium on the Foundations of

Software Engineering (FSE-9), 2002.

[7] I. Crnkovic and M. Larsson, editors. Building Reliable Component-Based Real-Time Systems. Artech

House Publishers, July 2002.

[8] K. R. Dittrich and A. Geppert. Component Database Systems, chapter Component Database Systems:

Introduction, Foundations, and Overview. Morgan Kaufmann Publishers, 2000.

[9] A. Geppert, S. Scherrer, and K. R. Dittrich. KIDS: Construction of database management systems

based on reuse. Technical Report ifi-97.01, Department of Computer Science, University of Zurich,

September 1997.

[10] The genric modeling environement. Institute for Software Integrated Systems, Vanderbilt University,

http://www.isis.vanderbilt.edu /Projects/gme/, December 2004.

[11] T. Gustafsson and J. Hansson. Data management in real-time systems: a case of on-demand updates

in vehicle control systems. In Proceedings of 10th IEEE Real-time Applications Symposium (RTAS’04),

pages 182–191. IEEE Computer Society Press, 2004.

REFERENCES 29

[12] J. R. Haritsa and S. Seshadri. Real-time index concurrency control. IEEE Transactions on Knowledge

and Data Engineering, 12(3):429–447, 2000.

[13] S.-J. Ho, T.-W. Kuo, and A. K. Mok. Similarity-based load adjustment for real-time data-intensive

applications. In Proceedings of the 18th IEEE Real-Time Systems Symposium (RTSS’97), pages 144–

154. IEEE Computer Society Press, 1997.

[14] Developing DataBlade modules for Informix-Universal Server. Informix DataBlade Technology. Informix

Corporation, 22 March 2001. Available at http://www.informix.com/datablades/.

[15] K.-D. Kang, S. H. Son, J. A. Stankovic, and T. F. Abdelzaher. A QoS-sensitive approach for timeliness

and freshness guarantees in real-time databases. In Proceedings of the 14th IEEE Euromicro Conference

on Real-time Systems (ECRTS’02), pages 203–212. IEEE Computer Society Press, 2002.

[16] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier, and J. Irwin. Aspect-

oriented programming. In Proceedings of the 11th European Conference on Object-Oriented Programming

(ECOOP’97), volume 1241 of Lecture Notes in Computer Science, pages 220–242. Springer-Verlag, 1997.

[17] Y. Kim, M. Lehr, D. George, and S. Son. A database server for distributed real-time systems: Issues

and experiences. In Proceedings of the 2nd Workshop on Parallel and Distributed Real-Time Systems,

Cancun, Mexico, April 1994.

[18] Y.-K. Kim and S. H. Son. Supporting predictability in real-time database systems. In Proceedings

of the 2nd IEEE Real-Time Technology and Applications Symposium (RTAS’96), pages 38–48. IEEE

Computer Society Press, 1996.

[19] K. Y. Lam and W. C. Yau. On using similarity for concurrency control in real-time database systems.

The Journal of Systems and Software, 43(3):223–232, 1998.

[20] C.-G. Lee, Y.-K. Kim, S. H. Son, S. L. Min, and C. S. Kim. Efficiently supporting hard/soft deadline

transactions in real-time database systems. In Proceedings of the 3rd International Workshop on Real-

Time Computing Systems and Applications, pages 74–80, 1996.

REFERENCES 30

[21] J. Lindstrom, T. Niklander, P. Porkka, and K. Raatikainen. A distributed real-time main-memory data-

base for telecommunication. In Proceedings of the International Workshop on Databases in Telecommu-

nications, volume 1819 of Lecture Notes in Computer Science, pages 158–173, 1999.

[22] C. Lu, J. A. Stankovic, G. Tao, and S. H. Son. Feedback control real-time scheduling: Framework,

modeling and algorithms. Journal of Real-time Systems, 23(1/2), July/September 2002.

[23] MBrane Ltd. RDM Database Manager. http://www.mbrane.com.

[24] Universal data access through OLE DB. OLE DB Technical Materials. OLE DB White Papers, 12 April

2001. Available at http://www.microsoft.com/data/techmat.htm.

[25] D. Nystrom, A. Tesanovic, M. Nolin, C. Norstrom, and J. Hansson. COMET: A component-based real-

time database for automotive systems. In Proceedings of the IEEE Workshop on Software Engineering

for Automotive Systems, pages 1–8, May 2004.

[26] D. Nystrom, A. Tesanovic, C. Norstrom, J. Hansson, and N-E. Bankestad. Data management issues

in vehicle control systems: a case study. In Proceedings of the 14th IEEE Euromicro International

Conference on Real-Time Systems (ECRTS’02), pages 249–256. IEEE Computer Society Press, 2002.

[27] M. A. Olson. Selecting and implementing an embedded database system. IEEE Computers, 33(9):27–34,

Sept. 2000.

[28] S. Olson, R. Pledereder, P. Shaw, and D. Yach. The Sybase architecture for extensible data management.

Data Engineering Bulletin, 21(3):12–24, 1998.

[29] All your data: The Oracle extensibility architecture. Oracle Technical White Paper. Oracle Corporation.

Redwood Shores, CA, February 1999.

[30] Pervasive Software Inc. Pervasive.SQL Database Manager. http://www.pervasive.com.

[31] Polyhedra Plc. Polyhedra database manager. http://www.polyhedra.com.

REFERENCES 31

[32] A. Rashid. A hybrid approach to separation of concerns: the story of SADES. In Proceedings of the 3rd

International REFLECTION Conference, volume 2192 of Lecture Notes in Computer Science, pages

231–249, Kyoto, Japan, September 2001. Springer-Verlag.

[33] M. Sanfridson. Problem formulations for qos management in automatic control. Technical Report

TRITA-MMK 2000:3, ISSN 1400-1179, ISRN KTH/MMK–00/3–SE, Mechatronics Lab KTH, Royal

Institue of Technology (KTH), Sweden, March 2000.

[34] O. Spinczyk, A. Gal, and W. Schroder-Preikschat. AspectC++: an aspect-oriented extension to C++.

In Proceedings of the 40th International Conference on Technology of Object-Oriented Languages and

Systems (TOOLS’02), Sydney, Australia, February 2002. Australian Computer Society.

[35] J. Stankovic, S. Son, and J. Liebeherr. Real-Time Databases and Information Systems, chapter BeeHive:

Global Multimedia Database Support for Dependable, Real-Time Applications, pages 409–422. Kluwer

Academic Publishers, 1997.

[36] C. Szyperski. Component Software - Beyond Object-Oriented Programming. Addison-Wesley, 1999.

[37] A. Tesanovic, P. Mu, and J. Hansson. Development environment for configuration and analysis of

embedded real-time systems. In Proceedings of the 4th International Workshop on Aspects, Components,

and Patterns for Infrastructure Software (ACP4IS’05), March 2005.

[38] A. Tesanovic, S. Nadjm-Tehrani, and J. Hansson. Component-Based Software Development for Embed-

ded Systems - An Overview on Current Research Trends, volume 3778 of Lecture Notes in Computer

Science, chapter Modular Verification of Reconfigurable Components, pages 59–81. Springer-Verlag,

2005.

[39] A. Tesanovic, D. Nystrom, J. Hansson, and C. Norstrom. Embedded databases for embedded real-time

systems: a component-based approach. Technical report, Department of Computer Science, Linkoping

University, and Department of Computer Engineering, Malardalen University, 2002.

REFERENCES 32

[40] A. Tesanovic, D. Nystrom, J. Hansson, and C. Norstrom. Integrating symbolic worst-case execution

time analysis into aspect-oriented software development. OOPSLA 2002 Workshop on Tools for Aspect-

Oriented Software Development, November 2002.

[41] A. Tesanovic, D. Nystrom, J. Hansson, and C. Norstrom. Aspect-level worst-case execution time

analysis of real-time systems compositioned using aspects and components. In Proceedings of the 27th

IFAC/IFIP/IEEE Workshop on Real-Time Programming (WRTP’03), Poland, May 2003. Elsevier.

[42] A. Tesanovic, D. Nystrom, J. Hansson, and C. Norstrom. Aspects and components in real-time system

development: Towards reconfigurable and reusable software. Journal of Embedded Computing, 1(1),

October 2004.

[43] Aleksandra Tesanovic. Developing Reusable and Reconfigurable Real-Time Software using Aspects and

Components. PhD thesis, Department of Computer and Information Science, Linkoping University,

Sweden, March 2006.

[44] TimesTen Performance Software. TimesTen DB. http://www.timesten.com.

[45] K. L. Wu, P. S. Yu, and C. Pu. Divergence control algorithms for epsilon serializability. IEEE Trans-

actions on Knowledge and Data Engineering, 9(2):262–274, March-April 1997.

[46] Xerox Corporation. The AspectJ Programming Guide, September 2002. Available at:

http://aspectj.org/doc/dist/progguide/index.html.

[47] M. Xiong and K. Ramamritham. Deriving deadlines and periods for real-time update transactions. In

Proceedings of the 20th IEEE Real-Time Systems Symposium (RTSS’99), pages 32–43. IEEE Computer

Society Press, 1999.

[48] P. S. Yu and D. M. Dias. Impact of large memory on the performance of optimistic concurrency control

schemes. In Proceedings of the International Conference on Databases, Parallel Architectures, and Their

Applications (PARBASE’90), pages 86–90. IEEE Computer Society Press, 1990.

Index

AOSD, 7

aspect

run-time, 24, 26

aspect package

concurrency control, 15

index, 13, 15

QoS, 13, 15

COMET, 14

admission control, 17

configuration, 14

FC-M, 19

GUARD, 15

HP-2PL, 15

ODC, 15

QMF, 19

QOS, 17

RM, 19

STR, 19

FC-M, 19

GUARD, 15

HP-2PL, 15

least square regression, 19

ODC, 15

QMF, 19

RM, see least square regression

run-time aspects, 24

self-tuning, 19

STR, see self-tuning

WCET, 26

33

application-tailored databases for real-time systems

Documents