a distributed database system based on database migration and its mechanism for concurrency control
TRANSCRIPT
A Distributed Database System Based on Database Migration
and Its Mechanism for Concurrency Control
Takahiro Hara, Kaname Harumoto, Masahiko Tsukamoto, and Shojiro Nishio
Department of Information Systems Engineering, Graduate School of Engineering, Osaka Un iversity, Suita, Japan 565-0871
SUMMARY
In this paper, we discuss our proposal of a distributed
database system, DB-MAN (distributed database system
based on DataBase Migration in ATM Networks), which
takes advantage of database migration in virtual local area
networks (LANs) of ATM networks. DB-MAN has two
notable mechanisms: a mechanism for selecting the trans-
action processing method and a mechanism for concur-
rency control with database migration. The former is a
mechanism that chooses the more efficient method between
two transaction processing methods: the conventional
method based on the two-phase commit protocol and our
method employing database migration. The latter is a
mechanism to prevent the transaction processing through-
put from deteriorating in environments where data conten-
tion is a significant factor. Then we show simulation results
regarding performance comparison between our proposed
system and the conventional distributed database system
based on the two-phase commit protocol. The obtained
results demonstrate that effective use of database migration
gives higher performance than that of the conventional
system. © 1999 Scripta Technica, Syst Comp Jpn, 30(5):
28�37, 1999
Key words: Database migration; ATM (asynchro-
nous transfer mode); concurrency control; distributed data-
base.
1. Introduction
Because of the recent development of network tech-
nologies such as asynchronous transfer mode (ATM), very
high speed data transmission is becoming available. The
evolution of broadband networks affects the design of da-
tabase management systems. The most important issue for
performance improvement of a networkwide database sys-
tem is the effective use of broadband networks, and this is
contrary to a typical conventional situation where the mini-
mization of data volume transmitted in (narrowband) net-
works is considered as the primary factor for performance
improvement.
Here, the question is how we can use broadband
networks efficiently. A possible answer is to make a data-
base migrate from one site to another site through networks.
We call the migration of a database DB-migration [7]. In
the conventional distributed database environment, each
database is fixed at a particular site and a typical database
operation is performed through several operation request
messages. In the conventional method, transaction process-
ing often requires many message transmissions, while if we
use DB-migration, there is no need for exchanging mes-
sages after a transaction initiation site has gathered the
necessary databases. This means that the transaction proc-
essing time of the method based on DB-migration can be
much shorter when the transaction is complex [5, 6].
Based on this fact, in our previous work [3], a trans-
action processing method has been proposed which makes
effective use of DB-migration. This method adaptively
chooses the more efficient method of either the conven-
tional database-fixed method (fixed-processing method) or
CCC0882-1666/99/050028-10
© 1999 Scripta Technica
Systems and Computers in Japan, Vol. 30, No. 5, 1999Translated from Denshi Joho Tsushin Gakkai Ronbunshi, Vol. J81-D-I, No. 6, June 1998, pp. 819�828
28
the method using DB-migration (migration-processing
method). The method selection is based on the complexity
of the transaction and the access pattern of each site. From
simulation experiments, we have verified the effectiveness
of the proposed method in environments where no two
transactions are processed concurrently.
However, since DB-migration is an operation that
occupies a database for some time, it is expected that the
system performance deteriorates due to the introduction of
DB-migration when transactions occur frequently. In this
paper, we propose a distributed database system, DB-MAN
(distributed database system based on DataBase Migration
in ATM Networks), which has two notable mechanisms:
adaptive selection of the transaction processing method
based on the method in Ref. 3 and concurrency control for
DB-migration. In DB-MAN, we extend the conventional
two-phase lock protocol (2PL) by adding two new locks,
the move lock for data items and the location lock for
databases, to the conventional read and write locks. More-
over, by supporting read and write operations to a migrating
database, the DB-MAN system prevents the transaction
processing throughput from deteriorating in environments
where data contention is a significant factor. We also show
the simulation results regarding performance evaluation of
our proposed system.
The rest of the paper is organized as follows. In
section 2, we show the system architecture of DB-MAN.
Section 3 describes the mechanisms for concurrency con-
trol in DB-MAN. Section 4 presents simulation results.
Finally, in section 5, we summarize the paper.
2. Distributed Database System DB-MAN
In this section, first we describe the basic system
model for discussing DB-MAN. Then, we explain the struc-
ture of the DB-MAN system.
2.1. Model
In this paper, we assume that a distributed database
system is constructed using a virtual LAN (VLAN) in ATM
networks. In ATM networks, a VLAN can be constructed
independent of a physical network topology. A VLAN is
realized by choosing a certain site as an MCS (multicast-
server) and establishing a point-to-multipoint PVC connec-
tion from the MCS to each site on the VLAN. Each site can
broadcast data through the VLAN by sending data to the
MCS (see Figure 1).
In this system model, we also make the following
assumptions:
x Except for the broadcast messages in the VLAN,
all communication is performed over a point-to-
point SVC connection that is established on de-
mand.
x If an SVC connection is once established for proc-
essing a transaction, it is not released during the
execution of the transaction.
x We assign a unique database identifier (DB-id) to
each (local) database located in the VLAN.
x Very high speed database access can be realized
by utilizing the techniques of main memory data-
base systems [1, 2].
x The migration of indexes can be realized by ap-
plying the mechanism of secondary index migra-
tion, which is offered in the distributed system
based on data item migration [8].
2.2. Behavior of DB-MAN
In this subsection, we explain the behavior of the
DB-MAN system. The DB-MAN system is a distributed
database system constructed in an ATM VLAN. Each site
in the system has its local database management system
(LDBMS). The LDBMS of the transaction initiation site
parses transactions (or queries) into several subqueries and
then chooses the fixed- processing method or the migration-
processing method to execute the transaction.
When the fixed-processing method is chosen, as
shown in Fig. 2(a), the LDBMS of the transaction initiation
site executes the subqueries by communicating with sites
that hold databases involved in the transaction. Finally, two
rounds of message transmissions for the 2PL are per-
formed.
When the migration-processing method is chosen, as
shown in Fig. 2(b), the LDBMS of the transaction initiation
site gathers databases involved in the transaction by three
communication operations: (1) DB request, (2) DB-migra-
tion, and (3) completion notification. We assume that the
databases involved in each transaction can be identified at
the beginning of the transaction, and let us call these data-
Fig. 1. Virtual LAN and message broadcasting.
29
bases the target databases. The DB request message is
broadcast to every site in the VLAN, and thus all sites can
get information on the location of each database associated
with an invoked transaction. In this way, it is possible for
each site to maintain the information on database locations.
The completion notification message is also broadcast to
every site, and thus all sites can recognize the completion
of the database relocation. Then, the LDBMS of the data-
base sender sites can delete copies of transmitted databases
that are maintained preparing migration failures. After the
above processes are completed, the LDBMS of the transac-
tion initiation site executes the transaction processing.
2.3. System architecture of DB-MAN
Figure 3 illustrates the system structure of the
LDBMS in the DB-MAN. In the middleware of the
LDBMS, transactions issued by client applications are ana-
lyzed and fragmented into several subqueries so that the
executor can execute them. Moreover, one of the fixed-
processing method or the migration-processing method is
chosen to execute the transaction. Seven functions of the
LDBMS are as follows.
2.3.1. Transaction analyzer
The transaction analyzer accepts transactions (or
queries) from client applications. It parses, optimizes, and
fragments the incoming queries into several subqueries and
passes them to the method selector. It also passes the
information on the target databases and the number of
message transmission required for the fixed-processing
method to the method selector.
2.3.2. Method selector
The method selector adaptively determines which of
the two methods�the fixed-processing method or the mi-
gration-processing method�should be used for each trans-
action. This choice is performed based on some
information, such as the information from the query proc-
essor, and the recent transaction access pattern.
For choosing the processing method, the following
two methods proposed in Ref. 3 are used:
Simple mode�The simple mode estimates the com-
munication times of the fixed-processing method and the
migration-processing method and simply chooses the
method with a shorter communication time.
Log-statistics mode�In choosing the processing
method, the log-statistics mode uses the usage-log and the
continuous-use declaration that is made to a database when
the transaction initiation site uses the database continuously
in the next transaction, as well as the estimated communi-
cation times of the two processing methods. In order to
maintain the usage log of each database, every site monitors
the broadcast messages for lock requests. The information
for the continuous-use declaration is also transmitted to
every site together with the messages for lock requests.
If the fixed-processing method is chosen, the method
selector passes the subqueries to the coordinator. On the
other hand, if the migration-processing method is chosen,
the method selector passes the list of target databases to the
DB migrator and the (unfragmented) queries to the coordi-
nator.
2.3.3. DB migrator
The DB migrator, which has accepted the list of target
databases, transmits a broadcast message for DB request.
When the migration of the databases is completed, the DB
migrator transmits a broadcast message to notify comple-
tion.
Fig. 2. Communication process of the fixed-processing
method and the migration-processing method.
Fig. 3. Structure of DB-MAN.
30
2.3.4. Coordinator
The role of the coordinator is to perform the
(sub)queries such that the consistency of the whole data-
base is not violated. If a (sub)query cannot be executed
locally, then the coordinator constructs a request to the
LDBMS (the concurrency controller and the executor) of a
site that can perform the (sub)query by means of an opera-
tion request message. Otherwise, the coordinator requests
the storage manager to process the (sub)query. Then, it
returns the final result to the client application and performs
the 2PL to commit the transaction.
2.3.5. DB information manager
The DB information manager maintains the informa-
tion on location, size, continuous-use, and usage log of each
database and provides the information to every function of
the system. In order to maintain the information, it monitors
the broadcast messages for DB request, completion notifi-
cation, and lock requests, and updates the database infor-
mation of its own site such as locations of databases.
2.3.6. Concurrency controller
The concurrency controller passes the operation re-
quests (write, read, and move) to the executor in proper
timing based on the lock state. We discuss the details in the
next section.
2.3.7. Executor
The executor manages three direct operations,
namely, write, read, and move, to the databases.
x It executes the operations to the database(s) based
on the accepted (sub)queries and returns the re-
sults to the coordinator of the transaction initiation
site.
x If the accepted DB request message includes the
DB-id of the database that its own site holds, the
coordinator transmits the database(s) to the trans-
action initiation site.
After it receives the completion notification message,
the site deletes the copy (copies) of the database(s).
3. Concurrency Control Mechanism of
DB-MAN
This section describes a mechanism for the concur-
rency control of DB-MAN.
Moreover, we also discuss a mechanism for recovery
when DB-migration fails or a transaction abort occurs.
3.1. Mechanism for concurrency control
Since DB-migration occupies a database for some
time, in order to prevent transaction processing throughput
from deteriorating in environments where data contention
is a significant factor, DB-MAN must adopt the following
strategies for the concurrency control as well as the conven-
tional concurrency control for read and write operations to
data items.
x The strategy to avoid the deadlock of several DB-
migration requests
x The strategy to support read and write operations
to a migrating database
Moreover, keeping the independence of the method
selection mechanism and the concurrency control mecha-
nism, we must use the following strategies:
x The strategy to prevent a database from migrating
from the transaction initiation site to another site
when the transaction initiation site has gathered
these databases employing DB-migration and will
be processing the transaction.
x The strategy to choose the transaction processing
method considering the transactions waiting for
their turns to be processed. In other words, the
information on the future locations of the target
databases and the information on the database
usage log at a point of time when the initiated
transaction is executed must be precisely known.
To support the above four strategies, we extend the
conventional 2PL protocol by adding two new locks�the
move lock for data items and the location lock for data-
bases�to the conventional read and write locks. Table I
shows the compatibility matrix of these locks. DB-migra-
tion occurs when the move lock is set to all data items of
the target database. The move lock cannot be set where the
write lock has already been set.
In DB-MAN, a transaction is processed in the follow-
ing steps:
1. At the time a transaction is initiated, a broadcast
message including each lock needed for processing the
transaction is transmitted. If the transaction is processed by
the migration-processing method, this message can be
added to the message for the DB request.
2. Utilizing the fact that a broadcast message is first
transmitted to the MCS, a sequence number, which we call
a transaction identifier (Tid), is assigned to the request
message (i.e., to the initiated transaction) at the MCS.
3. At each site that holds database(s), the lock queues
(for read, write, and move locks) are maintained for every
31
data item of the database(s). For example, if a database
consists of ten data items, ten lock queues are maintained
for the database. The lock requests accepted from the trans-
action initiation site are inserted into the appropriate
queues. Note that the move lock is inserted into all queues
of the target database.
4. The transaction initiation site knows the Tid as-
signed to its transaction from the returned (broadcasted)
message that the site sent to the MCS for the broadcast of
lock request. This Tid is inserted into every message for
operation requests in the transaction, and then the site
begins to transmit the messages to the appropriate sites.
5. In each site that holds the target databases, database
operations are executed based on the compatibility matrix
of locks shown in Table 1.
As shown in Table 1, the move lock cannot be set
where the write lock has already been set, and therefore
DB-migration does not excessively occur and each transac-
tion is processed nearly in the order that transactions are
initiated.
In the rest of this subsection, we discuss how the
aforementioned four strategies are realized based on these
processing steps.
Avoidance of deadlock
Deadlock can be avoided by using pure 2PL, that is,
it can be avoided by setting all locks that are necessary for
the transaction in advance of each transaction execution.
However, deadlock can occur when the arrival order of the
messages for lock requests is reversed at several sites for
some reasons, even if each transaction transmits a broadcast
message for all lock requests in advance of the transaction
execution.
In DB-MAN, since the Tid allocated at the MCS is a
sequence number, the transactions can be put in order
uniquely. If somehow the arrival order of the messages for
lock requests is reversed at several sites, we can revise the
order by comparing the Tid. However, there are also situ-
ations in which the arrival order of the messages is reversed
when no waiting request exists and the system starts to
process the operation. In this case, if the lock request with
smaller Tid arrives while the operation with larger Tid is
being executed, the system stops the executing operation
and starts to process the operation that arrived later. When
the operation with larger Tid has already been finished, the
order is not revised if only the reversed transaction has
already been committed. Otherwise, the reversed transac-
tion aborts and the operation that arrived later is executed.
Therefore, in any situation, deadlock cannot occur in
DB-MAN. Although this kind of deadlock avoidance
method requires more complex processing than the
timeout-based method, it can be done in a short period
by using main memory databases and thus higher
throughput is achieved.
Method selection considering the waiting transac-
tions
To implement this strategy, each site in the DB-MAN
system must precisely predict the future information that is
needed for method selection. In the simple mode, each site
monitors the broadcast messages for DB requests (i.e.,
requests for locks) from other sites and then predicts the
future locations of the databases when all waiting transac-
tions have been processed. Thus, each site maintains infor-
mation on both the real current locations and the future
locations of the databases, and method selection is per-
formed using the latter.
In the log-statistics mode, in addition, each site also
monitors the broadcast messages for lock requests in the
case of the fixed-processing method and then predicts the
future database usage log when all waiting transactions
have been processed. The site also maintains both informa-
tion on the database usage log of the last |L| transactions
that have already been processed and that of the last |L|
transactions that have arrived at the system. Method selec-
tion is performed using the future information on the loca-
tion and the database usage log. The predicted future
information is correct unless DB-migration fails or a trans-
action abortion occurs. The recovery from such cases will
be discussed later.
DB-MAN also avoids improper DB-migration
caused by wrong predicted information on the database
locations. The transaction initiation site adds the pre-
dicted locations of the target databases (similar to the
DB-id) to the broadcast message for DB request (lock
request). At each site that holds the target databases, the
real future locations caused by the last DB request and
the predicted locations in the new accepted message are
compared. Only if they are the same locations will the
move lock be inserted into the lock queues of all of the
data items of the target databases. Otherwise, the DB
request will be canceled.
Table 1. Lock compatibility matrix
Request
State
Read Write Move Location
Read T F T T
Write F F T T
Move T F F F
Location T T � �
T (True), F (False)
32
3.2. Support for operations to a migrating
database
While a database is migrating, a copy is maintained
at a sender site to prepare for migration failures. In this way,
the system can continue to execute the read and the write
operations to the migrating database by operating to the
copy. After confirming the completion of DB-migration,
DB-MAN stops the operation to the copy and sends the log
information for the operations executed to the copy to the
database receiver site. Then, the operations executed to the
copy are reflected in the real database. After completing a
series of the above processes, DB-MAN starts to execute
the operations to the database at the database receiver site.
The operation request messages that arrive after sending the
log information are forwarded to the database receiver site.
3.3. Protection to DB-migration by other
transactions
In DB-MAN, after the move locks have been set on
all data items of a database, DB-migration starts and all of
their move locks are unset. Moreover, the location lock is
set to the database. As shown in Table 1, the move lock
cannot be set where the location lock is set to the database.
Since the location lock is not unset until the transaction that
gathers the database using DB-migration is completed, the
transaction initiation site can process the transaction lo-
cally.
3.4. Mechanism for recovery
In DB-MAN, the recovery mechanisms proposed in
Ref. 4 are employed to keep the consistency of databases
against the system failures and transaction abortions. In
Ref. 4, the recovery methods that are extensions of the
conventional recovery methods for main memory database
have been proposed in order to support DB-migration. In
this subsection, we discuss the recovery methods in order
to perform the method selection effectively in DB-MAN.
As mentioned above, in the log-statistics mode, the
transaction initiation site must predict the future informa-
tion on the locations of the target databases and the database
usage log. Considering the fact that transaction abortions
and database migration failures affect such information, we
must additionally consider the recovery of the information.
In DB-MAN, the following three levels are provided for the
recovery:
Level 1:
x No recovery is executed in cases where transac-
tion abortions or database migration failures oc-
cur.
Level 2:
x If a DB-migration failure occurs, the transaction
initiation site (i.e., receiver site of the DB migra-
tion) transmits a broadcast message to notify the
failure. At each site that holds a database, the site
cancels lock requests from the transactions that
have Tids larger than that of the transaction in
which DB-migration fails. Moreover, at every site,
the future information on the database usage log
is discarded. Then, the site reinitiates the transac-
tion using the information on the real location of
the database and the database usage log of the last
|L| transactions that have already been processed.
x No recovery is executed in the case of transaction
aborts.
Level 3:
x The same recovery as level 2 is executed in the
case of DB-migration failures.
x If the transaction abortion occurs, the transaction
initiation site broadcasts the abort message instead
of transmitting this message only to the sites at
which the target databases reside. At each site that
holds a database, the site cancels lock requests
from the transactions whose Tids are larger than
that of the transaction in which the transaction is
aborted. Moreover, at every site, the future infor-
mation on the database usage log is discarded.
Then, the site reinitiates the transaction using the
information on real location of the database and
the database usage log of the last |L| transactions
that have already been processed.
In the environments where transactions are not initi-
ated so frequently (i.e., at each instant, there are few trans-
actions waiting to be processed), the recovery level should
be set to level 1 since the overhead of the recovery is light.
On the other hand, in the environments where transactions
are initiated frequently, the recovery level should be care-
fully chosen. Especially, we should consider seriously
whether to execute the recovery for DB-migration failures
or not. This is because the accuracy of the information on
a database location affects the transaction processing time.
In general, DB-MAN does not execute the recovery for
DB-migration failures in the environments where transac-
tions are initiated frequently and the ratio between the
frequency of DB-migration failure and transaction initia-
tion (the migration-failure/transaction ratio) is high, that
is, the recovery level is set to level 1. In the environments
where transactions are initiated frequently and the migra-
tion-failure/transaction ratio is low, if transaction abortions
and transaction initiations are frequent, the recovery level
is set to level 2. Otherwise, it is set to level 3.
33
Note that in the simple mode, the system provides
only two recovery levels for transaction abortions since this
mode does not use the database usage log.
4. Simulation
In this section, we present simulation results regard-
ing the performance evaluation of the DB-MAN system. In
the simulations, the interval of transaction initiation is
determined based on exponential distributions. We measure
the average transaction processing time of 10,000 transac-
tions required for the conventional fixed-processing
method, the migration-processing method, and those of
both (simple and log-statistic) modes of DB-MAN. For the
characteristics of databases and transactions, we make the
following assumptions:
x Each database consists of 30 data items. If the data
model is relational, a data item may be a single
relation.
x Each transaction consists of a sequence of at least
one write operation, and a write operation can be
executed only after the completion of the previous
operation in the sequence. Thus, in the fixed proc-
essing method, an operation request message can
be sent only after the completion of the previous
operation.
x Because DB-MAN employs the main memory
databases, the execution time of each write opera-
tion is far shorter compared with the communica-
tion time for transaction processing. Thus, we
assume that the operation execution time is negli-
gible.
The basic parameters used in the simulations are
summarized in Table 2. The number of database sites and
the number of databases, |S| and |D|, are 20 each. Database
Di (i = 1, . . . , 20) initially resides at site Si. We changed the
transaction initiation probability of each site Si in every
1000 transaction initiations between pi1 and pi
2 in order to
examine the adaptability of our proposed system. The wide
value range of nc (from 1 to 30) is intended to represent
transactions of various complexity. The parameters related
to data transmission are based on the future prospect of
distributed systems having worldwide scale. More specifi-
cally, first, the values of the propagation delays represent
the worldwide ATM-VLAN with fiberoptic cables in which
the average hop count between two arbitrary sites is about
10 and the average switching delay at an arbitrary ATM
switch is 5 ms (this value is based on the switching delays
of the present-day commercial ATM switches). Thus, the
value of the bandwidth reserved for DB migration, 1.0 and
2.0 Gbits/s, is based on the prospect that network bandwidth
will soon become a few gigabits per second worldwide. The
assumed size of the whole database represents the most
remarkable case in which the fixed-processing method and
Table 2. Parameter configuration for the simulation experiments
Parameter Meaning of the parameter Value
|S| Total number of sites in the VLAN 20 (site identifier S1, . . . , S20)
|D| Total number of databases in the VLAN 20 (DB-id D1, . . . , D20)
Size(Dj) Size of the database Dj 30 + 1.5j Mbytes ( j = 0, . . . , 19)
pi1
Transaction initiation probability 1 at site Si 0.025 (i = 1, . . . , 10), 0.05 (i = 11, . . . , 18),
0.15 (i = 19), 0.3 (i = 20)
pi2
Transaction initiation probability 2 at site Si 0.025 (i = 11, . . . , 20), 0.05 (i = 3, . . . , 10),
0.15 (i = 2), 0.3 (i = 1)
dMCS Propagation delay from the transaction initiation site to
the MCS
0.12 s
d Propagation delay between two sites 0.12 s
BM Reserved bandwidth for migrating databases 1.0 Gbit/s, 2.0 Gbits/s
C�k� Time required for establishing SVC connections 0.3k s
|L| Size of the usage log 20
P PCUD coefficient 0.02
K Log-dependent coefficient 0.10
34
the migration-processing method give almost the same
processing time when the network bandwidth is 1.5
Gbits/s. The PCUD coefficient P and the log-dependent
coefficient K are defined in Ref. 3, and they determine
the degree of priority given the continuous-use declara-
tion and the database usage log, respectively. These val-
ues are chosen by other simulations so that the system
gives the highest performance in environments where no
data contention occurs.
Based on this parameter configuration, our simula-
tion studies were executed in the following steps:
1. A transaction initiation site SI is determined ac-
cording to the transaction initiation probability of each site.
2. |DU|, the number of databases required for the
transaction (|DU| t |DN|), is determined as an integer value
at random from 1 to |D|. If SI has already made continuous-
use declaration for certain databases, and the value of |DU|
is smaller than the number of the databases that have been
declared to be used continuously, a new value is assigned
to |DU| such that the value is equal to the number of these
databases.
3. As the target databases, |DU| databases are se-
lected. Note that if SI has made continuous-use declaration
in the previous transaction, the databases declared to be
used continuously must be included in these |DU| data-
bases.
4. The number of write operations nc is determined
as an integer value at random from 1 to 30. Note that, among
nc write operations, nc|DN|/|DU| (operations) are for the
databases DN and the rest are for the databases DU � DN.
Then, within this constraint, the databases and the data
items of the databases that are the targets for the operations
are randomly selected.
5. The transaction continuity parameter E is deter-
mined. This parameter is determined randomly from the
values 0, 1, and 2, and it declares how many transactions SI
will initiate successively after the completion of the current
transaction.
6. If the value of E is larger than 0, the transaction
initiation probability of SI is increased by 1.00 in successive
E transaction(s). Then, the databases that are used continu-
ously are determined at random among the target databases.
7. In the case of the adaptive modes of DB-MAN,
the fixed-processing method or the migration-processing
method is chosen.
8. The locks for transaction execution are re-
quested, and the transaction is processed (according to the
chosen method in the case of the adaptive modes of DB-
MAN).
Figures 4 and 5 show the average transaction proc-
essing time of the four methods, changing the mean trans-
action interval by 0.1 from 0.1 to 20.0. They show the
results for the cases of BM = 1.0 Gbit/s and BM = 2.0 Gbits/s,
respectively. Here, in the simulations, we assume that band-
width reservation failures, system failures, and transaction
abortions do not occur. In both figures, the horizontal axis
indicates the mean transaction interval.
From these figures, it is seen that the processing time
of the migration-processing method is heavily affected by
the available network bandwidth. Also, in both cases, the
performance of the migration-processing method is the first
to deteriorate as the transaction initiation interval gets
shorter. This is because contentions of DB-migration re-
quests frequently occur in this method when transactions
are initiated in short intervals. As for our proposed system,
both modes of DB-MAN give almost the same performance
of concurrency control as the fixed processing method.
These results show that the concurrency control mechanism
of DB-MAN prevents the performance deterioration caused
by DB-migration in environments where data contention is
a significant factor. The simulation results also demonstrate
the effectiveness of the method selection mechanism in our
proposed system. Among the four methods, the log-statis-
tics mode gives the shortest processing time in both cases
where BM = 1.0 and 2.0 Gbits/s. Both modes in DB-MAN
give almost the same performance for BM = 2.0 Gbits/s
because, in most cases, the processing time of the migra-
tion-processing method is shorter than that of the fixed-
processing method, and then both modes frequently choose
the migration-processing method.
Fig. 4. Relation between the transaction initiation
interval and the transaction processing time of the four
methods (BM = 1.0 Gbit/s).
35
5. Conclusions
In this paper, we have proposed a distributed database
system, DB-MAN, that has two notable mechanisms: a
mechanism for selecting the transaction processing method
based on Ref. 3 and a mechanism for concurrency control
considering DB-migration. We also have verified the effec-
tiveness of DB-MAN by simulation experiments. The
mechanism for concurrency control in DB-MAN can pre-
vent the performance deterioration caused by DB-migra-
tion in environments where data contention is a significant
factor.
In the simulation experiments, the log-statistics mode
always gives better performance than the simple mode.
However, it must not be concluded that the log-statistics
mode is always superior to the simple mode in a real
environment because we have not taken the protocol over-
head into account in the simulation experiments.
As part of our future work, we are planning to imple-
ment our proposed system in a practical platform to evalu-
ate the system in several aspects including the protocol
overhead other than the throughput.
Acknowledgments. This research was supported
in part by Grants-in-Aid for Scientific Research 09780380
and 10780260 from the Ministry of Education, Science,
Sports, and Culture, Japan, and Research for the Future
Program of Japan Society for the Promotion of Science
under the Project �Integrated Network Architecture for
Advanced Multimedia Application Systems.�
REFERENCES
1. DeWitt D, Katz R, Olken F, Shapiro L, Stonebraker
M, Wood D. Implementation techniques for main
memory database systems. Proc ACM SIGMOD�84,
p 1�8.
2. Garcia-Molina H, Lipton RJ, Valdes J. A massive
memory machine. IEEE Trans Comput 1984;C-
33:391�399.
3. Hara T, Harumoto K, Tsukamoto M, Nishio S. Trans-
action processing using database migration in ATM
networks. Trans IEICE 1997;J80-D-I:505�513. (in
Japanese)
4. Hara T, Harumoto K, Tsukamoto M, Nishio S. Main
memory database for supporting database migration.
Proc IEEE Pacific Rim Conference on Communica-
tions, Computers and Signal Processing (IEEE PAC-
RIM �97), vol.1, p 231�234.
5. Hara T, Harumoto K, Tsukamoto M, Nishio S. Loca-
tion management for database migration in ATM
networks. Trans IEICE 1997;J80-D-I:137�145. (in
Japanese)
6. Hara T, Harumoto K, Tsukamoto M, Nishio S. Loca-
tion management methods of migratory data re-
sources in ATM networks. Proc ACM Symp on
Applied Computing (ACM SAC�97):123�130.
7. Nishio S. Tsukamoto M. Towards new multimedia
information bases in broadband networks. Trans
IEICE 1996;79-D-II:460�467. (in Japanese)
8. Stonebraker M, Aoki PM, Devine R, Litwin W, Olson
M. Mariposa: A new architecture for distributed data.
Proc 10th Int Conf on Data Engineering, 1994:54�
65.
Fig. 5. Relation between the transaction initiation
interval and the transaction processing time of the four
methods (BM = 2.0 Gbit/s).
36
AUTHORS (from left to right)
Takahiro Hara received his B.E. and M.E. degrees in information systems engineering from Osaka University in 1995
and 1997, respectively. Currently he is a research associate in the Department of Information Systems Engineering, Osaka
University. His research interests include distributed database systems in advanced computer networks, such as high-speed ATM
networks and mobile computing environments. He is a member of three learned societies, including IEEE.
Kaname Harumoto received his B.E., M.E., and D.Eng. degrees in computer science from Osaka University in 1992,
1994, and 1998, respectively. Currently he is a research associate with the Faculty of Engineering, Osaka University. His research
interests include technologies for database management systems, especially in combination with modern network technologies,
such as high-speed ATM networks and mobile computing environments. He is a member of three learned societies, including
IEEE.
Masahiko Tsukamoto received his B.E., M.E., and D.Eng. degrees from Kyoto University in 1987, 1989, and 1994,
respectively. From 1989 to 1995, he was a research engineer with Sharp Corporation. He then became assistant professor in the
Department of Information Systems Engineering at Osaka University, and since 1996, has been an associate professor there.
He is a member of seven learned societies, including ACM and IEEE. His current research interests include database systems,
knowledge-base systems, and distributed computing systems.
Shojiro Nishio received his B.E., M.E., and D.Eng. degrees from Kyoto University in 1975, 1977, and 1980, respectively.
From 1980 to 1988, he was with the Department of Applied Mathematics and Physics, Kyoto University. He then joined the
Department of Information and Computer Sciences, Osaka University. Since 1992, he has been a professor in the Department
of Information Systems Engineering there. His current research interests include database systems, knowledge-base systems,
and distributed computing systems. He has served on the editorial board of IEEE Transactions on Knowledge and Data
Engineering and is currently on the editorial boards of Data & Knowledge Engineering, New Generation Computing,
International Journal of Information Technology, Data Mining and Knowledge Discovery, and The VLDB Journal. He is a
member of six learned societies, including ACM and IEEE.
37