A New Transaction Management Scheme for Mobile

A New Transaction Management Scheme for Mobile Computing Environments Khalil M. Ahmed

Mohamed A. Ismail Nagwa M. El-Makky Department of Computer Science Faculty of Engineering, Alexandria University Alexandria, Egypt {khalil, mismail, nagwa, mnagi}@alex.eun.eg

Abstract Tremendous advances in computer hardware and communication have made mobile computing feasible. In this paper, a new transaction management scheme for mobile computing environments is proposed. The proposed scheme attempts to support desired features in the mobile computing paradigm while complying with the existing constraints imposed by the mobile environment. It is scalable for a growing number of mobile units and is tuned for the expected workload by providing special processing of read-only transactions. It supports the various modes of operation of a mobile unit, namely, the fully connected, partly connected, and fully disconnected modes and allows a smooth transition between them. It attempts to minimize wireless communication, specially in the up-link direction from the mobile unit to the mobile support station, one of the most scarce resources in the mobile environment. A queuing network is proposed to model the system. A simulator, based on this model, is built to verify and analyze the behavior of the proposed transaction management scheme. Keywords: Mobile computing environments, Distributed database systems, Transaction management, Performance evaluation, Simulation and system modeling

1. Introduction Tremendous advances in computer hardware and communication have made mobile computing feasible. Users will be able to gain access to global information systems using their Mobile Units (MUs) supplied with wireless communication devices by communicating with fixed Mobile Support Stations (MSSs). That access to global information systems will be performed using transactions. However, the new mobile computing environment poses several physical and logical constraints that are not present in traditional distributed database systems. Therefore, existing solutions for traditional distributed transaction management are not readily applicable to mobile transactions because of the difference in cost/performance issues. The database research community is beginning to revise traditional distributed transaction management to be adapted to pull the best out of the growing mobile computing paradigm. Several valuable attempts have been made to efficiently support mobile transactions. However, each attempt considers

Khaled M. Nagi

only a subset of the operational requirements. For example, in [19], the authors present a mobile transaction model for the batch mode of operation. In [3], the authors investigate caching strategies to support read-only transactions. Isolation Only Transactions (IOT) [12] is a research aiming at providing transactional services, for the Coda file system [10], which support the full disconnection mode. Another research supporting disconnected operation is exposed in [17]. It uses semantics-based transaction processing techniques for mobile transactions. The research in [9] presents a concurrency control algorithm that reduces messages flowing in the fixed network in a mobile environment. This paper proposes a transaction management scheme that supports the various modes of operation of MUs, namely, the fully connected, fully disconnected, and partly connected modes and allows a smooth transition between them. It is also a scalable scheme, i.e., its performance does not degrade severely when the system scale is enlarged, as verified by the simulation results in Section 6. In order to improve response time and to deal with disconnection problems, the scheme makes use of the MU resources such as fixed storage in replication purposes such as caching data items at the MU and view materialization. To improve performance, the proposed scheme is tuned for the workload nature that is expected to exist in such environments. The key factor of this workload is the high rate of readonly transactions. Hence, special processing for read-only transactions is provided. Also, in order to further improve performance, the scheme is easily adapted to support operations on weakly consistent data. While doing all this, the main objective is to attempt to minimize wireless communication, specially in the up-link direction (from the MU to the MSS), the most scarce resource in the mobile environment, even at the cost of increasing the down-link communication (from the MSS to the MU). To do so, the proposed scheme utilizes the broadcasting capabilities of the MSSs. However, the scheme does not lay much overhead on the MSSs, for example, by making them as stateless as possible. The remainder of the paper is organized as follows. Section 2 gives an overview of the mobile environment. Section 3 introduces the proposed transaction management

Hand-off

en e

Fully Connected

RP

Doze Mode

RP

2.1 Constraints imposed by the mobile environment

2.2 Different operation modes of an MU Various operation modes are needed to cope with the above constraints. The different modes of operations are shown in the state transition diagram of Figure 1. It is adapted from [14] and its enhancement in [15]. It can be seen that the decisive factor in the degree of connection is the availability of bandwidth [15]. Fully Connected (FC): In this state, the MU is fully connected to the fixed network. Partly Connected (PC): The MU should be switched to operate in this mode if the bandwidth becomes scarce. Supporting this mode of operation is a key feature of the proposed transaction management scheme. Throughout this paper, this mode of operation is used to indicate that the

RP

stands for a Recovery Protocol

PartialConnection Protocol

of

Disconnection Protocol

Hand-off

The above described model poses several constraints on the new information system paradigm. The wireless communication suffers from the low bandwidth as well as the high variance in bandwidth availability. The communication environment is also highly asymmetric. This fact makes sending from the MUs very expensive in comparison with receiving in terms of power consumption. Power limitation and battery lifetime of the MUs are expected to remain a scarce resource in the new environment. For the same reason, broadcasting from the MSS is readily available whereas it is virtually impossible from MUs. Finally, beside being monetarily expensive, MUs suffer from frequent, yet predictable, disconnection.

t ou or e th n g id a w gr nd din ba n w se lo

rg y co ns re id er m cei at es pt io sa of ns ge a ny

Hand-off Protocol

battery, failure, or out of range

The most widely accepted model of the mobile environment, as presented in [8], consists of two distinct sets of entities: Mobile Units MUs and Fixed Hosts. The fixed hosts are connected to a high speed fixed network. Some of them are supplied with wireless devices in order to communicate with the MUs. Such hosts are called Mobile Support Stations MSSs. Each MSS covers an area, called a cell, in which the MUs can communicate with. The transition of an MU from a cell to another is called Handoff [7]. It is assumed that each MSS has a coordinator which receives transaction operations from the MUs and monitors their execution in database servers within the fixed network.

e

2. The Mobile Computing Environment

MU can establish a down-link (from the MSS to the MU) but cannot establish an up-link (from the MU to the MSS) connection. This mode of operation goes in harmony with the physical characteristics of wireless networks. Doze Mode: in which the clock speed of the processor is reduced and virtually no computation is done. Fully Disconnected (FD): If the MU is out of any MSS cell range, it is completely disconnected. However, this should not be treated as a network failure and any transaction that is submitted to the fixed hosts should be completed and the result saved until the MU connects itself again.

th

scheme. Section 4 presents the proposed queuing network model of the mobile environment. Sections 5 and 6 present the simulation study conducted to verify and analyze the behavior of the proposed transaction management scheme. Finally, Section 7 concludes the paper.

Partly Connected Hand-off

Disconnection Protocol

Fully Disconnected

Hand-off

Figure 1: Operation modes of an MU

3. The Proposed Mobile Transaction Management Scheme In this section, The proposed mobile transaction management scheme is presented. A correctness proof of the scheme is given in [13].

3.1 Scheme outline The new scheme uses the Optimistic Concurrency Control approach [11]. Its basis is the Isolation-Only Transactions model of [12] which with several modifications can support the features stated in Section 1. Figure 2 is a simplified state transition diagram of a transaction running under the proposed transaction management scheme. MUs cache frequently accessed database items in their fixed storage in order to deal with the problem of disconnection and to improve response time. So, a transaction running at an MU reads data items locally if they are present at the MU and are valid or must request them from the MSS in case of the FC mode of operation. By data item, it is meant either a data page or an entire object. Granularity of data

items has been under many researches such as [6]. Write operations of updater transactions are done locally in a temporary workspace in the MU. When all operations of the transaction are performed, it moves to the validation phase. Read-only transactions validate locally as will be described in subsection 3.1.1. For an updater, the MU sends the transaction read and write sets to the MSS for remote validation. The transaction is assigned a unique commit timestamp by its MSS coordinator. Validation is done by certifying the read and write requests of the transaction in all the involved servers, as in [16]. If the validation succeeds, the items of the transaction write set will be committed to the servers, otherwise, the transaction will be aborted. If the MU cannot establish an up-link communication with the MSS, the transaction is moved to the pending state waiting for reestablishing connection. Upon reconnection, the pending transaction is sent to the MSS for validation. Suspended d en sp Su

Local read & write

m su Re

End Transaction & need for a missing up-link connection

Re mo te

Da ta

Tr an sa cti on

on Up

R

Pending

n tio ec nn o ec

In the proposed scheme, invalidation reports are periodically sent to all MUs in the cell range using the broadcasting capabilities of the MSS. They identify data items that have been updated in the MSSs since the publication of the last invalidation report; hence invalidating some of the cached items at the MUs. Since invalidation reports do not carry the data values themselves, but rather the data items identifiers, they do not consume much of the available wireless channel bandwidth. Invalidation reports have many advantages. Firstly, the MUs need not to establish an up-link connection to an MSS to invalidate their caches. A PC mode is sufficient to listen to invalidation reports. Secondly, invalidation reports allow local validation of read-only transactions. It suffices that upon reaching the validation phase, the MU transaction manager is to wait for the next invalidation report, if none of the data items present in the read set of a transaction were invalidated and the transaction is not dependent on any other pending transactions, the transaction could commit locally without the need to contact the MSS. Thirdly, invalidation reports cause the proposed scheme to be categorized as a kill-based scheme instead of a die-based one as it immediately aborts a conflicting transaction instead of doing useless work. Finally, The MSSs need not to be stateful servers [3], thus reducing the overhead of keeping track of the MUs and their caches in their cells.

Validation

(kill)

Abort

n io at ss lid ce va uc S

Waiting for remote data item

En d

t bor ly A Ear

rea d item s en the t MU to

Running

V a Fa lida ilu tio re n

Begin Transaction

e

3.1.1 invalidation reports

Commit

Figure 2: Transaction state transition diagram In order to assure data items replication consistency, each replica at an MU or at a server is supplied with a version identifier V_ID. This V_ID contains the commit timestamp of the transaction that updated the data item. V_IDs enable checking that an MU transaction has not manipulated an outdated copy and hence are a key factor in validating transactions. If a transaction did manipulate an outdated copy, it has to be aborted as soon as the MU discovers this inconsistency. The whole transaction is restarted once again. Unlike blocking concurrency control algorithms [2], aborted transactions under the proposed scheme can restart immediately without staying for a certain delay.

Invalidation reports have to be broadcasted periodically [3], instead of asynchronously after the commitment of each transaction as proposed in traditional Client/Server concurrency control algorithms [e.g., 5], in order to impose a fixed delay before committing read-only transaction locally. The main disadvantage of invalidation reports is that the MU will have to process these reports and probably read reports immaterial to it. This overhead can be significantly reduced if the reports were divided into sections. Then, the MU can ignore processing the sections not in its interests. The granularity of sectioning will remain an open question for studies. Also, if the MUs were equipped with wireless devices that are able to receive many broadcasted channels, data could be divided into several channels [8]. Another disadvantage is a slight increase in the amount of data broadcasted by the MSS which is negligible against the size of data items values flowing from the MSS to MUs if the caching were disabled.

3.1.2 update reports During its running, a transaction may be suspended several times upon receiving a report broadcasted by the MSS (The various types of broadcasted reports are discussed in Sections 3.1.1, 3.1.2, and 3.1.3). After handling the report, the MU resumes the suspended transaction.

Supporting the PC mode of operation is a key feature of the proposed scheme. It is supported through invalidation reports and update reports. Update reports present a solution to the problem that arises in restarting transactions in

PC MUs because some of the data items needed in the transaction will be marked as invalid at the MU and it is not possible to request a read operation from the MSS due to the disconnection. The proposed solution to this problem is that the MU, prior to its disconnection, downloads the data items it expects to be using during disconnection. Also, it has to request the MSS to periodically broadcast changes done to these data items in Update Reports. Update reports have several advantages. They constantly refresh data in the PC MUs; raising the percentage of committed transactions. Moreover, if some of the transactions are aborted, the user still has a chance to restart them instead of waiting for restart upon restoring full connection. Update reports are sent periodically but in a lower frequency than invalidation reports. A transaction running in a PC MU is suspended until the next update report when it attempts to read an invalid data item. Update reports are also vital to the implementation of materialized views which are discussed in subsection 3.1.2.1.

3.1.2.1 materialized views View materialization offers more flexibility than basic caching as it allows different levels of consistency according to the semantics of the application. It is vital for the success of the PC operations and could be also used on a smaller scale in the FC operations as another strategy for caching. Profiting from a support of weak consistency, the size of the update report can be made significantly smaller. This is due to the fact that data included in the update report are those being updated since the last update report, and being requested for materialization by some MU, and having broken the consistency criteria for this data item.

3.1.3 smooth state transition and Dump reports The proposed scheme supports smooth state transitions from any mode of MU operation to the other with no extra information. The only real problem is supporting the transition from the FD state to the PC state as there is no way of checking the validity of the data items cached at the MU. There are two possible solutions to this problem. Either the transition from the FD to the PC state is prohibited: an FD MU is only allowed to restore total connection or stay FD even if it is in the PC cell region; or the MSS is required to periodically broadcast all data requested for downloading in dump reports. Listening to these reports, an MU changing its state from FD to PC determines the validity of its data items and hence aborting the conflicting transactions and preventing the blind processing of further dependent transactions. The second solution is comparable to the work presented in [1] which suggests the broadcast of the whole database on the air periodically. Certainly, broadcasting dump reports is the most expensive among all reports and must be done at a much lower frequency.

3.2 Scheme adaptation to support weak consistency The proposed transaction management scheme can be easily adapted to support weak consistency. Operation on weakly consistent data means accepting a divergence in a used data item from its correct value. The divergence criterion is based on the value of the data item. A time divergence can be easily mapped to a value divergence of the timestamp of the write operation. This timestamp can be broadcasted in invalidation and update reports with little overhead. Having defined the divergence criteria, there are two possible options for registering them: • the MSS must keep track of each MU registering the divergence criterion of each materialized view [18]; or • the MU must send the divergence criterion of each data item used in validating the transaction. As for the concurrency control algorithm itself, the following must be done in the case of an FC MU: • Upon the receipt of a data item, in an invalidation report, that might invalidate a transaction, the data item must be read from the MSS to ensure that the transaction is truly invalidated or not. If the server keeps track of materialized view subscription, it suffices to send an ignore message if the divergence criterion is not yet violated which minimizes broadcasting. • If the data item is materialized, the MU has the option to wait for the next update report which will then contain the value of the data item suspected for being invalid. This second option is the only option available in the PC mode of operation.

4. The Proposed Queuing Network Model In this section, the queuing network model developed to model the proposed transaction management scheme is presented. It is based on the most standard database system architecture [4] with some adaptation to support the new requirements. For example, Report Handlers are added at the MSSs/the MUs to generate/handle all types of reports. Also the MSS transaction manager is a newly introduced server at the MSS which acts as the interface module between the MSS and the MUs residing in its cell. It provides the MUs with their need of transactional support such as providing remote read operations, validating mobile transactions and coordinating transactional handoff services. The network can be logically divided in three parts: the MU, the wireless network, and the MSSs together with the fixed network. Figure 3 represents the queuing network model for the MU and the wireless network side. Figure 4 represents the MSS side with its interface with the wireless network and the other fixed hosts through the fixed network. The various paths employed by the customers (transaction and control operations) are enumerated and can be

followed on both figures. A detailed description of these paths is included in [13].

BM RH RM TM

0 1 2 3 4 5 6

Buffer Manager Report Handler Recovery Manager Transaction Manager

Begin Read Write Request Validate Arrive Commit Arrive Abort Report

5.2 Mobile transaction model Table 2 contains mobile transaction model parameters. The values for these parameters are based on a typical mobile application, such as a salesperson application. Then, they are mapped to the miniature settings of Table 1. During simulation runs, the transition from FD to PC is prohibited because dump reports are not used as a design option for its expected high cost.

6 Report Trash Can

6

R H

BROADCASTING

Xaction

Aborting

6

Xaction

Pending

3

6

1, 4, 5

6

1,3

1, 3

R M

T M

1,4,5 Wireless Network

n

mitted

Xactio

Resub

0,1,2,3

B M

0,1,2,4,5,6 5

3

0,1,2,3

0,1,2,4

5.3 Physical resource model

MU Committed

Workl oad

transactions

Restart Delay

Transaction

Figure 3: Queuing network model (MU Side) Begin Read Write Request Validate Arrive Commit Arrive Abort Report

DM Data Manager GTM Global Transaction Manager LM Log Manager LTM Local Transaction Manager MSS TM MSS Transaction Manager RH Report Handler RM Recovery Manager

1,3

MSS 3

1

1,4,5 3

3

1

6 before image

3

R H

3

Wireless Network

6

D M

After image

1,3,6

R M

3

3

3 1

1 L T M

1,3

3

Action Queue

1,3

M S S T M

4,5 1,3

6

1,3

1, 4, 5

G T M

1,3

Subaction Queue

BROADCASTING

Fixed Network Leading to other GTMs

1

0 1 2 3 4 5 6

scaling, the number of MUs is also reduced which, in turn, makes simulation runs more feasible.

L M

3 6

Bulk Arrival And Bulk Service

Figure 4: Queuing network model (MSS Side)

5. The Simulation Study A simulator, based on the queuing network model of Section 4, is built to verify and analyze the behavior of the proposed scheme. The selected performance indices are: the throughput, the transaction response time, the abort probability, the up-link communication cost and the downlink communication cost. The following subsections present the system parameters and settings.

5.1 Database and workload models Table 1 contains database and workload parameters. A small database is used to make simulations involving large MU data caches feasible in terms of simulation time. Each MU generates a single stream of transactions. To cope with this miniature setting, transaction lengths are reduced and so are relevant parameters consequently. This solution is similar to that’s of several researches analyzing the performance of concurrency control algorithms in Client/Server environments such as [5]. As a result of such

Table 3 describes the physical resource models parameters which are based on the queuing network model presented in Section 4. In order to simplify the simulation, the wireless network and the MSSs are simplified to sources for providing remote data items and validating the transactions needing remote validation. System-wide parameters DBSize 1500 DataItemSize 1,024 Bytes NoOfMUs 20 Per MU InterTransactionDelay 0.0 sec. TransactionRestartDelay 0.0 sec. ReadOnlyTransactionProb 0.7 MinNoOfItemsInaTransaction 20 MaxNoOfItemsInaTransaction 30 UpdateProb (in an updater transaction) 0.2 MeanReadDelay 0.2 sec. MeanWriteDelay 0.4 sec. Prob. of accessing a data item in the hot region 0.8 No. of data items in the MU hot region of the DB 50 Table 1: Database and workload parameters InvalidationReportTimeInterval UpdateReportToInvalidationReportRatio DataItemHeaderSize CheckStateTransitionTimeInterval StateTransProb

3.0 sec. 1:2 32 Bytes 30 sec. FC PC FD FC 07 . 03 . 00 . PC 02 . 07 . 01 . FD 03 . 00 . 07 .

MaterializedSizeForanFC_MU 10 data items MaterializedSizeForaPC_MU 60 data items Table 2: Mobile transaction model parameters MU specific parameters MUCacheDBSize LocalReadTime LocalWriteTime

300 items 0.02 sec. 0.04 sec.

TimeForHandlingOneInvalidation-Entry 0.005 sec. TimeForHandlingOneUpdateEntry 0.055 sec. TimeForHandlingCommit/Abort 1.0 sec. MSS and wireless communication specific parameters NetworkMSSRemoteReadDelay 2.0 sec. NetworkMSSValidationDelay 4.0 sec. Table 3: Physical resource model parameters

6. Simulation Results 6.1 Scalability Scalability is a major factor in evaluating transaction management schemes for mobile environments as discussed in [7]. The number of MUs involved in the simulation is varied and the simulation is repeated for different mixes of read-only and updater transactions. In Figure 5, it can be seen that increasing the number of MUs does not cause thrashing in system throughput. Moreover, other performance indices, such as the response time, Figure 6, and the up-link communication, Figure 7, are even less affected. The only measure that incurs a large increase is the MSS broadcasting cost in number of bytes flowing from the MSS to MUs per second which is presented in Figure 8. This is due to the absolute increase in system throughput.

6.2 Effect of local commitment of Read-only transactions The support for local commitment of read-only transactions enhances almost all performance indices under study. In a typical mobile application workload, read-only transactions are expected to be at least 70% of the total workload. At this workload, system throughput, illustrated in Figure 9, is enhanced by approx. 20% compared to an unaware-of-transaction-type scheme. Similarly, the abort probability and response time (Figure 10 and Figure 11 respectively) are improved by an 8% factor. The most important improvement is the reduction in the up-link communication which is reduced by approx. 20% (Figure 12). The only increase in cost is the down-link communication traffic (Figure 13) which is increased by approx. 6% due to the increase in system throughput since the down-link communication per transaction is almost the same (Figure 14). The same trend of increase (or decrease) in the measured performance indices continues as the percentage of read-only transactions increases.

6.3 Effect of supporting the PC mode of operation The effect of supporting the PC mode of operation is analyzed by comparing a system configuration that supports PC and another that does not, using different mixes of read-only and updater transactions. Both configurations are identical in terms of average residence time in a connection state. The difference is that instead of an MU spending some time in the PC connection state in the first configuration, it will spend it in the FD connection state in the second configuration. Therefore, the stationary steady-state distribution of MU connection states is 43% for FD, 43% for PC, and 14% for FD in the first configuration as opposed to 43% for FD, 0% for PC, and 57% for FD in the second. The result of the experiments indicates the improvement in all performance indices under study. For an 80% read-only transactions workload, Figure 15 indicates an approx. 45% increase in overall system throughput, together with a 30% reduction in transaction response time as illustrated in Figure 16. The abort probability, illustrated in Figure 6.13Figure 17 is slightly decreased by a factor of 10% as the MU still suffers from being not fully connected. As for communication cost, the local commitment of readonly transactions and the early detection of abort substantially reduce the up-link communication by a factor of 35% in the 80% read-only workload as can be seen in Figure 18. The only increase in cost is in the update reports broadcasting cost because of the increase in the sizes of the reports due to the fact that PC MUs request the materialization of data items expected to be used during disconnection. However, this cost breaks even at the 55% read-only transactions workload as illustrated in Figure 19. As the percentage of updater transactions decreases, update reports tend to be shorter favoring the first configuration more and more.

7. Conclusion In this paper, a new transaction management scheme for mobile computing environments is proposed. The scheme attempts to support desired features in the mobile computing paradigm while complying with the existing

26

7000

2 .5 R e a d - o n ly %

24

1

20

Up-link Com. (Bytes/trans.)

1 .5

6000

0% 25% 50% 75% 100%

22

0% 25% 50% 75% 100%

Response Time (sec.)

System Throughput (trans./sec.)

R e a d - o n ly % 2

18

16

R e a d -o n ly % 4000

0% 25% 50% 75% 100%

3000

2000 14

0 .5 1000

12

0

0

10

5

10

15

20

25

5

10

15

20

25

No of M U s

4000 System Throughput (trans./sec.)

2500 2000

Read-only % 1500

0% 25% 50% 75% 100%

1000 500

10

15

1 .8

0 .7

1 .6

0 .6

1 .4

0 .5

1 .2

1

0 .8

25

0 .4

0 .3

R O A w a re

R O U n a w a re

20

20

0 .2

R O A w a re

0 .6

0 5

15

N o of M U s

Abort probability

4500

3000

10

Figure 7: Up-link communication

Figure 6: Response time

3500

5

No of M Us

Figure 5: System throughput

Down-link Com. (Bytes/sec.)

5000

0 .4

25

R O U n a w a re

0 .1

0

0

20

40

60

80

No of MUs

100

0

20

40

60

R e a d - o n ly %

Figure 8: Down-link comm.

80

100

R e a d - o n ly %


Figure 10: Abort probability 3500

18

7000

6000



16

RO Unaware

5000

15

3000

RO Aware


17

2500

4000

14

2000

3000

13

2000

RO Aware

12

RO Unaware

10

1000

0

20

40

60

RO Unaware

1000

11

0

RO Aware

1500

80

100

0

20

40

60

80

Read-only %

0

100 Read-only %

40

60

80

100

Read-only %

Figure 12: Up-link comm.


20


7000 26

1.4

24

1.2

5000 4000 3000

RO Aware

2000

RO Unaware 1000

22 1


System Throughput (trans./sec.)

Down-link Com. (Bytes/trans.)

6000

0.8

0.6

20

18

16

0.4

14

W ith PC W ithout PC

0.2

W it h P C W it h o u t P C

12

0 0

20

40

60

80

100

Read-only %


0

10 0

20

40

60

80

100

Read-only %


0

20

40

60

80

100

R e a d -o n ly %


8000

0.7

7000

Abort probability

0.6

0.5

0.4

0.3

With PC 0.2

3500

6000 5000 4000 3000

With PC

2000

Without PC

0

20

40

60

80

100

With PC

2000

1500

0

20

40

60

80

100

Read-only %

Read-only %

Figure 17: Abort probability

2500

Without PC

0

0

3000

Without PC

1000

0.1



0.8

Figure 18: Up-link comm.

physical and constraints imposed by the mobile environment. The simulator, that is based on the proposed queuing network model, verifies scheme scalability for a growing number of MUs. It gives a quantitative estimate of performance enhancement caused by its tuning for efficient support of read-only transactions which are expected to be at least 70% of the workload. Moreover, the results of the conducted experiments highlight the benefit of supporting the PC mode of operation. The benefit lies in three directions, namely: the superiority of the PC mode over the fully disconnected mode in terms of the studied performance indices; the battery saving of this mode of operation when compared to the FC mode; and the increase in cell ranges which leads to savings in the number and cost of MSSs.

References [1] S. Acharya, R. Alonso, M. Franklin, and S. Zdonik, “Broadcast Disks: Data Management for Asymmetric Communication Environments,” Proc. ACM SIGMOD, pp. 199-210, 1995. [2] R. Agrawal, M. Carey, and M. Livny, “Models for Studying Concurrency Control Performance Alternatives and Implications,” Proc. ACM SIGMOD, pp. 108-120, 1985. [3] D. Barbara and T. Imielinski. “Sleepers and Workaholics: Caching Strategies in Mobile Environments,” Proc. ACM SIGMOD, pp. 1-12, May 1994. [4] P. Bernstein, V. Hadzilacos, and N. Goodman, Concurrency Control And Recovery in Database Systems, AddisonWiesley, 1987. [5] M. J. Carey, M. J. Franklin, M. Livny, and E. J. Shekita, “Data Caching Tradeoffs in Client-Server DBMS Architectures,” Proc. ACM SIGMOD, pp. 357-366, 1991. [6] M. J. Carey, M. J. Franklin, and M. Zaharioudakis, “FineGrained Sharing in a Page Server OODBMS,” Proc. ACM SIGMOD, pp. 359-370, 1994. [7] A. Elmagarmid, J. Jing, and T. Furukawa, “Wireless Client/Server Computing for Personal Information Services and Applications,” SIGMOD RECORD, pp. 16-21, December 1995.

0

20

40

60

80

100

Read-only %


[8] T. Imielinski and B. R. Badrinath, “Mobile Wireless Computing: Challenges in Data Management,” Communications of the ACM, Vol. 37, No. 10, pp. 18-28, October 1994. [9] J. Jing, O. Bukhres, and A. Elmagarmid, “Distributed Lock Management for Mobile Transactions,” Proc. of the 15th Int’l Conf. on Distributed Computing Systems, June 1995. [10] J. J. Kistler and M. Satyanarayanan, “Disconnected Operation in the Coda File System,” ACM TOCS, Vol. 10, No. 1, pp. 3-25, February 1992. [11] H. T. Kung and J. T. Robinson, “On Optimistic Methods for Concurrency Control,” ACM TODS, 6(2), June 1981. [12] Q. Lu and M. Satyanaranyanan, “Isolation-Only Transactions For Mobile Computing,” Operating Systems Review, Vol. 28, No. 2, pp. 81-87, April 1994. [13] K. Nagi, A New Transaction Management Scheme and a System Management Tool for Mobile Databases, M. Sc. Thesis, Alexandria University, December 1996. [14] E. Pitoura and B. Bhargava, “Dealing with Mobility: Issues and Research Challenges,” TR: CSD-TR-93-070, 1993. [15] E. Pitoura and B. Bhargava, “Building Information Systems for Mobile Environments,” Proc. of the 3rd Int’l Conf. on Information and Knowledge Management, 1994. [16] M. Sinha, et al, “Timestamp based certification schemes for transactions in distributed database systems,” Proc. ACM SIGMOD, May 1995. [17] G. D. Walborn and P. K. Chrysanthis, “Supporting Semantic-Based Transaction processing in Mobile Database Applications,” Proc. 14th IEEE Symposium on Reliable Distributed Systems, 1995. [18] O. Wolfson, P. Sistla, S. Dao, K. Narayanan, and R. Raj, “View Maintenance in Mobile Computing,” SIGMOD RECORD, pp. 22-27, December 1995. [19] L. H. Yeo and A. Zaslavsky, “Submission of Transactions from Mobile Workstations in a Cooperative Multidatabase Processing Environment,” Proc. 14th Int’l Conf. on Distributed Computing Systems, June 1994.