a distributed database system based on database migration and its mechanism for concurrency control

10
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): 2837, 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, 1999 Translated from Denshi Joho Tsushin Gakkai Ronbunshi, Vol. J81-D-I, No. 6, June 1998, pp. 819828 28

Upload: takahiro-hara

Post on 06-Jun-2016

212 views

Category:

Documents


0 download

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