![](bg2.png)
most other database replication protocols.
The rest of the paper is structured as follows. Sec-
tion 2 describes the structure of RJDBC. Section 3 ex-
poses some results of the developed prototype, com-
paring it with other systems. Related work is de-
scribed in section 4. Finally, section 5 concludes this
paper.
2 ARCHITECTURE OF RJDBC
A database replicated by means of the RJDBC mid-
dleware is composed by multiple replicas accessible
via JDBC. In each node where a client application ex-
ists, there will be a RJDBC driver on top of RJDBC
core and the usual JDBC driver. As stated previously,
this RJDBC core uses a uniform atomic broadcast
protocol in order to intercommunicate the replicas.
Basically, each node pursues two main targets:
1. To spread all significant operations performed on
each node among all the nodes of the system, in the
same order. The operations are codified, packed in
some ready-to-transmit way and finally applied on
actual database objects.
2. To ensure database consistency among all the repli-
cas. Notice that all the operations arrive to each
node through an atomic broadcast protocol, so that
the same operation delivery order is guaranteed in
all nodes.
OPERATIONS FORWARDING ENGINE
OPERATIONS EXECUTION ENGINE
DBMS
APPLICATION
DISPATCHING
SERVICE
COMMUNICATIONS
JDBC
JDBC
RECEPTION
SERVICE
APPLICATION APPLICATION
Figure 1: RJDBC global architecture.
So, in order to reach these goals, each RJDBC node
can be roughly split up into two main components,
connected by means of a third one, the communica-
tions subsystem (figure 1):
1. The operations forwarding engine has the job of
broadcasting all the operations performed over the
local node among all the nodes of the RJDBC en-
vironment, including itself. It provides a JDBC in-
terface to the application layer and we refer to it as
RJDBC driver.
2. The operations execution engine feeds on the oper-
ations delivered by the communications subsystem.
It sequentially applies all received operations to the
underlying DBMS.
3. The communications subsystem consists of two
different elements, the dispatching service, which
broadcasts all the operations provided by the for-
warding engine, and the reception service, which
admits the broadcast operations and delivers them
to the operations execution engine.
The latter two components constitute the RJDBC
core.
Going into further details, the applications interact
with the RJDBC node through standard JDBC invo-
cations, using our RJDBC driver. Such driver com-
plies with the JDBC specification and provides all
the objects required for database accessing. These
objects wrap JDBC invocations and forward them to
the RJDBC core. These objects are named wrappers.
They stand for proxies of the actual JDBC database
objects. Thus, all database operations requested by
the client applications are immediately packed and
forwarded by the wrappers to the RJDBC core. This
communication takes place using Java RMI.
When the RJDBC core is notified about a new op-
eration, it promptly sends it towards all the system
nodes, including itself, using a uniform atomic broad-
cast (this implies total order). Not all operations are
required to be broadcast but only those affecting the
database management system state. For instance, if
the underlying database uses multi-version concur-
rency control, read-only accesses may not be trans-
mitted.
When a RJDBC node receives a new operation
from the communications protocol, it is enqueued for
subsequent processing. Each RJDBC node contains
an Operations Execution Thread (OET), in charge
of executing sequentially all enqueued operations.
This feature, plus the total order delivery, ensure the
database inter-replica consistency.
On the other hand, the OET does not apply oper-
ations over the database directly either. Instead, it
executes them over exact copies of the final JDBC
database objects, called adapters. These elements
allow fine grained control of operation execution re-
sults. They maintain a reference to the actual JDBC
database objects and execute the requested operations
on them, collecting the results and communicating
them to the OET.
In essence, each node consists of five components
arranged as figure 2 states. These components are:
the wrappers layer, the manager, the communications
layer, the operations execution thread and the adapters
layer.
• The wrappers layer provides access to the un-
derlying database management system, hiding the
ICEIS 2004 - DATABASES AND INFORMATION SYSTEMS INTEGRATION
588