Maintaining Data Consistency Using Timestamp Ordering in Real-Time Broadcast Environments* Victor C. S. Lee and Kwok-Wa Lam Department of Computer Science City University of Hong Kong
[email protected] Abstract The broadcast-based data dissemination in wireless environments poses new challenging issues on data consistency of transaction processing. In this paper, we first adapt the optimistic concurrency control with forward validation to the broadcast environments. The adapted protocol gives autonomy between the mobile clients and the server such that the mobile clients can read consistent data off the air without contacting the server. However, it suffers from excessive transaction restart that affects the timeliness of mobile transactions. Therefore, we propose a new protocol based on timestamp ordering that can show significant performance improvement. The timestamp ordering technique enjoys a number of benefits from flexible adjustment of serialization order by exploiting the semantics of readonly transactions, which comprise most of the existing applications. The simulation results confirmed that the proposed protocol could be an efficient and effective approach to transaction processing in real-time broadcast environments for meeting transaction deadlines.
1. Introduction In a wireless mobile network, the server may have a relatively high bandwidth broadcast capability while the bandwidth for mobile clients is very limited. Such asymmetric communication environments [1] render the conventional transaction processing mechanisms, which require bi-directional communication between the server and mobile clients, inapplicable since the time required for message passing between them may be intolerably long. Another issue is that data transmission from mobile clients over the air is monetarily expensive [10] due to the limited bandwidth [18]. Furthermore, the large population size of mobile clients may overload the server when they asynchronously submit data access requests to the server * Supported in part by contract IJRP-9803-6 from the Ministry of Information and Communication of Korea.
Sang H. Son Department of Computer Science University of Virginia
[email protected] for processing. To exploit the abundance of downstream communication capacity from the server to mobile clients, broadcast-based data dissemination such as broadcast disks [1] becomes a major mode of information transfer in mobile wireless environments [2,13,24]. The server continuously and repeatedly broadcasts all data objects in the database. The mobile clients view this broadcast as a disk and mobile transactions can read the values of data objects being broadcast. A periodic broadcast program is constructed to schedule the broadcast of data objects cyclically (broadcast cycle) according to certain popularity criteria. Many applications in broadcast environments are inherently of real-time nature. Real-time transactions from mobile clients are associated with timing constraints in form of deadlines. For instance, it may be a financial or opportunity loss if a stock trading transaction cannot be completed within a certain deadline. In addition, the temporal validity of some data objects such as stock price or sensor data poses another type of timing constraints to the database systems. Transaction correctness is then defined as meeting its timing constraints and using data that is absolutely and relatively timing consistent [23]. Many applications in mobile broadcast environments have read-only transactions. Read-only transactions do not modify any data [7]. Examples include information dispersal systems for temporal or time-sensitive information such as stock prices, traffic condition, weather information and electronic auctions. Specifically, in stock markets and electronic auctions, it is expected that the number of stock buyers or bidders is relatively few with respect to the number of speculators who will also look up (read) the prices frequently. The large population of readonly transactions makes the processing of read-only transactions an important performance issue in these applications. Although read-only transactions can be processed with conventional transaction processing algorithms, in many cases it is more efficient to process read-only transactions with special algorithms which take advantage of the knowledge that the transaction only reads [7]. Therefore, our proposed protocols exploit the
semantics of the read-only transactions from the mobile clients such that they are processed locally without communicating with the server. We assume that serializability is the notion of correctness in transaction processing [4]. Concurrency control protocols are used to control the execution of transactions in a serializable way. The two common approaches are based on locking and optimistic concurrency control. However, the locking-based concurrency control mechanisms are inapplicable for broadcast environments [22]. Acquiring locks for every data object by transactions generated by the mobile clients requires excessive bi-directional communication between mobile clients and the server. The large population of mobile clients may also overload the server with lock requests. The optimistic approach is more suitable for the asymmetric bandwidth of the broadcast environments. A straightforward way of using the optimistic approach can be that transactions that have finished the read phase are submitted to the server for validation. Then, the server broadcasts the validation results to the mobile clients. In addition to the consumption of upstream bandwidth for sending transactions to the server for validation, this method may suffer from the problem of late transaction restart. Late transaction restart occurs when a transaction to be restarted eventually is allowed to run to the end of execution. It is not desirable in real-time database systems. A transaction that destines to be restarted may miss its deadline due to the delay that includes both the communication delay and the wasted processing time. Furthermore, the processing of the to-be-restarted transaction may defer the execution of other active transactions (by contending for resources) such that their deadlines may be missed at the end, causing a loss-loss situation. Thus, we adapt the optimistic concurrency control protocol with forward validation such that transactions will be aborted and restarted as soon as data conflict is detected. As a result, transactions can be processed efficiently and timely. Section 2 discusses some related work. In Section 3, we discuss the importance of serializability. Section 4 describes the adapted protocol for processing read-only transaction in broadcast environments. In Section 5, an improved version called BCC-TI is proposed. The effectiveness of BCC-TI is explained in Section 6. The impact of different parameter settings on the performance of the proposed protocols is discussed in Section 7 and we conclude the study in Section 8.
2. Related Work Data management in broadcast environments receives a lot of attention in these few years [3,6,13,16,18,21]. However, there are only a few studies on transaction
processing [21]. In [11], Datacycle architecture is introduced for high throughput database systems. The entire contents of the database are repetitively broadcast to the hosts over a high bandwidth network. It could be very expensive to use the serializability as the correctness criterion in the Datacycle architecture [22]. In [22], a new correctness criterion is proposed to allow read-only transactions to read current and consistent data in broadcast environments without contacting the server. However, the serializability is not maintained in their protocol. Two different read-only transactions may perceive the effects of update transactions in different serial orders. It may be hazardous to certain applications such as mobile stock trading where a buy/sell trade will be triggered to exploit the temporary pricing relationships among stocks. From the trader’s perspective, the inability of database management system to maintain the serializability may have important financial consequences [5]. For instance, if the users who submitted multiple read-only transactions communicate and compare their query results, they may be confused [7]. In [22], they proposed two protocols, F-Matrix and R-Matrix. Although the F-Matrix shows better performance, it suffers from high overheads in terms of expensive computation and high bandwidth requirement for additional control information. In [19,20], a number of broadcast methods is introduced to guarantee correctness of read-only transactions. There is no real-time issue in their study. The multiversion broadcast approach broadcasts a number of versions for each data item along with the version numbers. This method increases considerably the size of the broadcast cycle and accordingly response time. Moreover, the serialization order is fixed at the beginning of the read-only transaction. It is very restrictive and lacks flexibility. In the invalidation-only broadcast, a read-only transaction is aborted if any data item that has been read by the read-only transaction was updated at the server. This method lacks concurrency. For the conflictserializability method, both the mobile clients and the server have to maintain a copy of the serialization graph for conflict checking. It incurs high overheads to maintain the serialization graph. The integration of updates into the local copy of the serialization graph and the cycle detection may be too computation intensive for certain portable mobile computers.
3. A Case for Serializability If a read-only transaction can read all data objects within a single broadcast cycle, the serializability is guaranteed. However, read-only transactions may span multiple cycles [5]. For instance, in the broadcast disks mechanism, the database may be partitioned into multiple disks that are broadcast in different cycles. In some cases,
a read operation of a transaction may depend on the value of the preceding read operations. Therefore, if there is no concurrency control, read-only transactions may read inconsistent data objects that have been updated by transactions at the server. Due to the asymmetric communication bandwidth between the mobile clients and the server, existing concurrency control protocols are not suitable for broadcast environments. Hence, recent work [21,22] relaxed the strictness of serializability and proposed some concurrency control protocols based on the relaxed consistency requirements for broadcast environments. While these protocols are useful in some applications, serializability may still be needed to guarantee the correctness of some applications in broadcast environments. Serializability is the standard notion of correctness in transaction processing [4] to preserve database consistency. When transactions are processed in a serializable manner, the database is guaranteed to remain in a consistent state. Therefore, the objectives of concurrency control are to maintain the serializability on one hand and to maximize concurrency on the other. To illustrate the importance of the serializability, let’s take mobile stock trading as an example. Consider two stocktrading read-only transactions Q1 and Q3 at mobile clients that read the stock prices of X and Y and compute composite indices of stocks X and Y with different weightings. Let U2 and U4 be update transactions at the server that update the prices of X and Y respectively. Assume that the price of stocks X and Y is both 100. Consider the following execution schedule: r1(X) w2(X) c2 r3(X) r3(Y) w4(Y) c4 r1(Y)…. If both Q1 and Q3 commit, then the server and both mobile clients would see serializable executions. The serialization order for the server is U2 → U4 whereas the serialization orders for Q1 and Q3 at the mobile clients are U4 → Q1 → U2 and U2 → Q3 → U4 respectively. Assume that the execution schedule is allowed and the stock price for X rises to 110 and is updated by U2 whereas the stock price for Y drops to 90 and is updated by U4. Since Q1 and Q3 perceive different serialization orders, Q1 will get a composite index assuming that stock Y drops and stock X remains unchanged whereas Q3 will get a composite index assuming that stock X rises and stock Y remains unchanged. As a result, the decision outcome of Q1 may be to shift the cash from Y to X and that of Q3 may be to shift the cash from X to Y, which is confusing. In fact, the global execution schedule (Q1 → U2 → Q3 → U4 → Q1) is not serializable and should not be allowed.
4. Optimistic Concurrency Control in Broadcast Environments
In this section, we adapt the optimistic concurrency control with forward validation (OCC-FV) [8,9,12] protocol to solve the late restart problem for read-only transactions at the mobile clients in broadcast environments. At the server, validation of a transaction is done against currently running transactions. This process is based on the assumption that the validating transaction is ahead of every concurrently running transaction still in the read phase in the serialization order. Thus, the detection of data conflicts is carried out by comparing the write set of the validating transaction and the read set of active transactions. That is, if an active transaction, Ti, has read a data object that has been concurrently written by the validating transaction, the value of the data object used by Ti is not consistent. In other words, when a readonly transaction at a mobile client reaches its validation phase and commits, no transaction will be aborted due to its commitment under OCC-FV since the write set of a read-only transaction is always empty. Making use of this characteristic of the OCC-FV protocol and the prior knowledge of read-only property of transactions, an adapted protocol called broadcast concurrency control with forward validation (BCC-FV), is proposed. During each broadcast cycle, the server stores the write set per transaction of all transactions committed in the current broadcast cycle (in the control information). In the next broadcast cycle, the server broadcasts this control information along with the data objects that are programmed for the cycle. The control information helps the mobile clients to determine whether their active readonly transactions have data conflicts with the committed transactions at the server. There is only one possible type of data conflict between the committed update transactions and the active read-only transactions: writeread conflict (e.g., WS(U) ∩ RS(Q) ≠ {}). If there is a data conflict, the conflicting read-only transaction will be aborted and restarted. Therefore, data conflicts can be detected at the early stage of the read-only transactions. Before read operations are performed on data objects that are broadcast during a cycle, all read-only transactions have to consult the control information received during that cycle to determine whether the execution can proceed. If the execution cannot proceed, the read-only transaction is aborted. For each read-only transaction, Q, at the mobile client, the following simple testing is performed before the remaining read operations. Let CUT be the set of update transactions that are committed in the last broadcast cycle. Let CRS(Q) be the current read set of Q. That is, CRS(Q) is the set of data objects that have been read by Q from previous broadcast cycles. Note that the write sets of the committed transactions are stored in the control information broadcast by the server. if WS(Ui) ∩ CRS(Q) ≠ {},∀ Ui ∈ CUT then restart (Q).
This adaptation has two advantages. Firstly, the late restart problem can be partly solved for read-only transactions. Secondly, the read-only transactions can be processed locally without communicating with the server. However, BCC-FV suffers from the unnecessary restart problem [15] because it has an implicit assumption that the committed update transactions always precede all the active read-only transactions in the serialization order. These unnecessary restarts should be avoided. The new protocol presented in the next section aims to avoid these unnecessary restarts.
5. The BCC-TI Protocol In this section, we present a new broadcast concurrency control protocol for read-only transactions, called Broadcast Concurrency Control using Timestamp Interval (BCC-TI).
5.1. Commit Phase of Update Transactions at the Server For every update transaction, a final timestamp is assigned when it commits. Let WS(U) be the write set of an update transaction, U, and TS(U) denotes the final timestamp of U. Let WTS(d) be the largest timestamp of committed update transaction that has written data object, d. Then, when U commits, the following steps will be performed. The control information table is used for the serializability check by read-only transactions (to be described later). Step 1 assign the current timestamp to TS(U). Step 2 copy TS(U) into WTS(d), ∀ d ∈ WS(U). Step 3 record TS(U) and WS(U) into the control information table.
5.2. Read Phase of Read-only Transactions at the Mobile Clients Every read-only transaction in the read phase is assigned a timestamp interval, which is used to record temporary serialization order induced during the execution of the transaction. At the start of execution, the timestamp interval of a read-only transaction is initialized as [0, ∝), i.e., the entire range of timestamp space. Whenever a serialization order of a read-only transaction is induced by its read operations or the serializability check against update transactions, its timestamp interval is adjusted to reflect the dependencies among the transactions. The detection of non-serializable execution by readonly transactions is achieved by using the timestamp intervals. Since the serialization order of read-only transactions is checked against committed update transactions, we need to use the timestamps of data
objects, i.e. WTS(d) of data object d. In the read phase, whenever a read-only transaction reads a data object, its timestamp interval is adjusted to reflect the serialization induced between itself and committed update transactions. Let LB(Q) and UB(Q) denotes the lower bound and the upper bound of the timestamp interval of a read-only transaction, Q, respectively. If the timestamp interval shuts out (LB(Q) ≥ UB(Q)), a non-serializable execution performed by the read-only transaction is detected, and the transaction restarts. The following procedure is performed whenever a read-only transaction, Q, reads a data object, d. Step 1 read (d); Step 2 LB(Q) = max (LB(Q) , WTS(d)); Step 3 if LB(Q) ≥ UB(Q) then restart (Q). In this protocol, early data conflict detection is achieved since read-only transactions conflicting with a committed update transaction would have been restarted before the end of their execution.
5.3. Data Broadcast During each broadcast cycle, the server broadcasts the control information along with the data objects that are programmed for the current cycle. The mobile clients use the control information for the data conflict check. There is only one possible type of conflict between the committed update transactions and the active read-only transactions: write-read conflict (e.g., WS(U) ∩ RS(Q) ≠ {}). In this case, the serialization order should be Q → U. That is, the timestamp interval of Q is adjusted to precede that of U. It implies that the writes of U have not affected the read phase of Q. Before read operations are performed on data objects that are broadcast during a cycle, all read-only transactions have to consult the control information received during that cycle to determine whether the execution can proceed. If the execution cannot proceed, the read-only transaction is aborted. When the read-only transaction Q, at the mobile client, wants to read a data item, the adjustment of timestamp intervals of the active read-only transaction is performed. Note that TS(U) and WS(U) are stored in the control information broadcast by the server. Step 1 UB(Q) = mini (TS(Ui), UB(Q)), ∀ Ui ∈ CUT AND WS(Ui) ∩ CRS(Q) ≠ {};
6. Effectiveness of the New Protocol The protocol offers autonomy between mobile clients and the server. At mobile clients, read-only transactions can read current and consistent data object off the air without contacting the server, while the serializability is maintained. Once all the requested data objects are read
by a read-only transaction, the transaction can commit without consulting the server. Another nice feature of the protocol is the flexible adjustment of serialization order of a read-only transaction with respect to update transactions. Regardless whether a data object written by a committed update transaction is broadcast before (or after) a read-only transaction at the mobile client starts to read the data object, the serialization order of the read-only transaction with respect to the committed update transaction can be adjusted. By using the flexible adjustment of serialization order, unnecessary restarts can be avoided, providing improved performance. However, these nice features do not come for free. The main cost for such benefits is the management of timestamp intervals for active read-only transactions and the cost for the maintenance and broadcast of the control information table. The management of timestamp intervals for active read-only transactions can be done efficiently by using a transaction table at the mobile clients. The transaction table contains information of active read-only transactions, including the current read set and the upper and lower bounds of the timestamp interval of every active read-only transaction. The information that is recorded in the control information table includes the timestamp, TS(U), and the write set, WS(U), of each committed update transaction, U, in the last broadcast cycle. Nevertheless, the amount of control information is comparatively much less than that of other protocols in the literature [19,22].
7. Performance Evaluation The simulation experiments are aimed at studying the performance of our proposed protocol (BCC-TI) in contrast with BCC-FV for concurrency control of readonly transactions of mobile clients in broadcast disk environments. We have not considered the effects of caching in this performance study. In other words, a readonly transaction may have to wait for the requested data object in the next broadcast cycle if the data object is missed (have been broadcast) in the current broadcast cycle. The performance of these protocols can be compared by the miss rate, which is the percentage of transactions missed their deadline. Another performance metric is restart rate, which is the average number of abort and restart before a transaction can be committed. Note that a transaction that has been aborted may meet its deadline. So, this metric can demonstrate the effectiveness of the protocols in reducing transaction restart. Transaction response time, which is the time elapsed when the transaction commits since a mobile client submits the transaction, is also collected. This metric includes the time involved in restarting the transaction, if it aborts due
to violation of serializability in BCC-TI or data conflict with the validating transaction in BCC-FV. Note that a transaction may be restarted more than once. The overhead cost to restart a read-only transaction at a mobile client is low in both protocols. Since the processing of read-only transactions at the mobile clients is completely transparent and independent to the server, no additional overhead will be generated at the server while read-only transactions are restarted at the mobile clients. At the mobile clients, the restarted transactions are reset to the original state and the data objects that have been read in the private workspace can be ignored.
7.1. Experimental Setup The simulation model [22] consists of a server, a client, and a broadcast disk for transmitting both the data objects and the required control information. The mobile clients only process read-only transactions while the server processes update transactions as well. A read-only transaction is processed until it is committed, even the deadline is missed. The deadline of a read-only transaction is assigned to be (current time + slack factor × predicted execution time) where predicted execution time is a function of transaction length, mean inter-operation delay and broadcast cycle length. The data objects that the transactions access are uniformly distributed in the database. Table 1 lists the baseline setting for the simulation experiments. The time unit is in bit-time, the time to transmit a single bit. For a broadcast bandwidth of 64 Kbps, 1 M bit-times is equivalent to approximately 15 seconds. Table 1. Baseline setting Parameter Value Mobile Clients Transaction Length (no. of read operations) Mean Inter-Operation Delay Mean Inter-Transaction Delay Slack Factor Concurrency Control Protocol
4 65,536 bit times (exp. distributed) 131,072 bit times (exp. distributed) 2.0 – 8.0 (uniformly distributed) BCC-TI
Server Transaction Length (no. of operations) Transaction Arrival Rate Read Operation Probability Number of Data Objects in Database Size of Data Objects Timestamp Size Concurrency Control Protocol Priority Scheduling
8 1 per 250,000 bit-times 0.5 300 8,000 bits 8 bits OCC-FV Earliest Deadline First (EDF)
The server fills the broadcast disk with the data at the beginning of a cycle. Each cycle consists of a broadcast of all the data objects in the database along with the associated control information. For BCC-TI, the control information consists of a table containing the timestamps and write sets of the committed update transactions during the last broadcast cycle and an array of length n containing the write timestamps of the data objects where n is the number of data objects in the database. Each element in the array is broadcast along with the corresponding data object. The response times are measured in bit-time and 90% confidence intervals were obtained with widths less than 5% of the point estimates of the response times.
7.2. Effect of Mobile Transaction Length Figure 1 gives the miss rate of the read-only transactions issued by mobile transactions as a function of the mobile transaction length. The mobile transaction length is the number of read operations in a mobile transaction. As the mobile transaction length increases, the miss rate of both protocols increases. A mobile transaction that reads more data objects has to wait for more number of broadcast cycles or has a longer transaction span. Consequently, it is more difficult for it to meet the deadline after abort and restart. Besides, a longer transaction span increases the probability to have data conflicts with the update transactions at the server, since the number of server transactions that coexist with the mobile transaction increases with the transaction length. BCC-FV is more sensitive to the mobile transaction length and the performance drops sharply when the mobile transactions contain more than 5 operations. On the other hand, the miss rate of BCC-TI is much lower than BCC-FV. The main reason for a lower miss rate is the reduction of unnecessary transaction restarts. The restart rate of the two protocols is shown in Figure 2. When the mobile transaction length is 5, every transaction is aborted and restarted once on average under BCC-FV. The results show that BCC-TI can effectively reduce the number of transaction restarts. It is confirmed that there is much room for a read-only transaction to be positioned between the update transactions in the serialization order. Figure 3 shows the transaction response time. The response time is mainly composed of two elements. The first one is the time to wait for the requested data objects. When a read operation of a mobile transaction arrives during a broadcast cycle, it has to wait for the requested data object until the server broadcasts it. However, if the data object is broadcast before the operation arrives, the mobile client has to wait for the same data object in the next broadcast cycle. Another element is transaction
restart. A transaction that has been aborted and restarted suffers from a longer response time and may miss the deadline at the end.
7.3. Effect of Server Transaction Arrival Rate Another factor that will affect the probability of data conflicts is the transaction arrival rate at the server. Generally, the increase in the server transaction arrival rates increases the probability of data conflicts. Figure 4 shows the impact of server transaction arrival rate on the two protocols in terms of miss rate. Given a small database size in the baseline setting, the miss rate of BCCFV increases sharply with the server transaction arrival rate. In contrast, the miss rate of BCC-TI remains relatively low and increases slowly. Different from the impact of mobile transaction length, the increase in the server transaction arrival rate will not increase the waiting time for requested data objects directly. However, it will increase the number of transaction restarts, which in turn increases the response time. In the baseline setting of our experiments, the data contention at the server is low so that we can focus on the primary impact of the server transaction arrival rate. The restart rate of the server transaction is lower than 0.4%. When the server transaction arrival rate is set to four times the baseline setting, the restart rate of the server transaction is still lower than 2.5%. However, if the data contention at the server is high, the number of transaction restarts at the server will increase. We expect that the performance of the two protocols will get worse in a high data contention environment while BCC-FV will suffer more.
7.4. Effect of Data Object Size In centralized or distributed environments, data object size will not affect the intensity of data contention. However, in broadcast environments, data object size affects the length of broadcast cycle, which in turn affects the probability of data conflicts. When the length of broadcast cycle increases, the average waiting time for a data object of a read-only transaction increases. The prolonged waiting time will increase the response time of the read-only transaction and the probability of data conflicts with the increasing number of server transactions. Figure 5 shows the miss rate of both protocols as a function of data object size. As the data object size increases, the miss rate of both protocols increases. However, the miss rate of BCC-TI increases at a slow rate whereas the miss rate of BCC-FV increases relatively fast.
8. Conclusions and Future Work In this paper, we first adapt the optimistic concurrency control with forward validation (BCC-FV) for the broadcast environments. Then an improved version, broadcast concurrency control with timestamp interval (BCC-TI) is proposed to reduce the number of unnecessary restarts at the mobile clients. One of the major challenges in broadcast systems is the limited upstream communication capacity from mobile clients to server. This limitation renders many conventional concurrency control protocols useless. Another challenge is to maintain the serializability of transactions, which is a crucial issue in several applications such as stock trading. BCC-TI offers a number of highly desirable features for applications running in broadcast environments. First of all, the serializability of read-only transactions can be maintained. Read-only transactions can be committed locally at mobile clients without upstream communication. BCC-TI can be easily integrated with other conventional concurrency control protocols that are employed to maintain the serializability at the server. Moreover, the flexible adjustment of serialization order of a read-only transaction with respect to update transactions helps to reduce the number of unnecessary restarts such that readonly transactions are more likely to meet their deadlines. A series of simulation experiments is performed to compare BCC-TI with BCC-FV. BCC-TI performs better than BCC-FV in all parameter settings in terms of miss rate, restart rate and response time. BCC-FV is sensitive to mobile transaction length, server transaction arrival rate and data object size. The main reason is the high number of unnecessary transaction restarts. Under BCC-TI, the number of transaction restarts is greatly reduced and a lower miss rate is resulted. We are now studying how to process update transactions, in addition to read-only transactions, at mobile clients effectively. We are also looking into different strategies [17] to resolve data conflicts between low priority transactions and high priority transactions so that the system can achieve a better real-time performance. We are also interested in the issue of cache management in broadcast environments. The high cost of wireless bandwidth and the relatively slow communication speed make mobile computing an area suitable for applying data similarity [14]. We plan to look into similarity-based protocols for broadcast environments.
9. References [1] Acharya, S., Alonso, R., Franklin, M., and Zdonik, S., “Broadcast Disks: Data Management for Asymmetric Communication Environments,” Proc. of the ACM SIGMOD Conference, pp. 199-210, 1995.
[2] Alonso, R., and Korth, H., “Database Systems Issues in Nomadic Computing,” Proc. of the ACM SIGMOD Conference, Washington D.C., pp. 388-392, 1993. [3] Barbara, D., and Imielinski, T., “Sleepers and Workaholics: Caching Strategies in Mobile Environments,” Proc. of the 1994 ACM SIGMOD international conference on Management of data, pp. 1-12, 1994. [4] Bernstein, P. A., Hadzilacos, V., Goodman, N., “Concurrency Control and Recovery in Database Systems,” Addison-Wesley, Reading, Massachusetts, 1987. [5] Bowen, T. F., Gopal, G., Herman, G., Hickey, T., Lee, K. C., Mansfield, W. H., Raitz, J., and Weinrib, A., “The Datacycle Architecture,” Communications of the ACM, vol. 35, no. 12, pp. 71-81, 1992. [6] Dunham, M. H., Helal, A., Balakrishnan, S., “A mobile transaction model that captures both the data and movement behavior,” Mobile Networks and Applications, vol. 2, pp. 149 – 162, 1997. [7] Garcia-Molina, H., and Wiederhold, G., “Read-Only Transactions in a Distributed Database,” ACM Transactions on Database Systems, vol. 7, no. 2, pp. 209-234, 1982. [8] Haritsa, J. R., Carey, M. J., and Livny, M., “On Being Optimistic about Real-Time Constraints,” Proc. of the 1990 ACM SIGACT-SIGART-SIGMOD Symposium on Principles of Database Systems, 1990. [9] Haritsa, J. R., Carey, M. J., and Livny, M., “Dynamic RealTime Optimistic Concurrency Control,” Proc. of the 11th IEEE Real-Time Systems Symposium, 1990. [10] Hayden, D., “The New Age of Wireless,” Mobile Office, 1992. [11] Herman, G., Gopel, G., Lee, K. C., and Weinrib, A., “The Datacycle Architecture for Very High Throughput Database Systems,” Proc. of the ACM SIGMOD Conference, pp. 97-103, 1987. [12] Huang, J., “Real-Time Transaction Processing: Design, Implementation, and Performance Evaluation,” Ph.D. Dissertation, 1991. [13] Imielinski, T., and Badrinath, B. R., “Mobile Wireless Computing: Challenges in Data Management,” Communications of the ACM, vol. 37, no. 10, pp. 18-28, 1994. [14] Kuo, T. W., and Mok, A. K., “Load Adjustment in Adaptive Real-time Systems,” Proc. of 12th IEEE Real-Time Systems Symposium, pp. 160-170, 1991. [15] Lee, J., and Son, S. H., "Using Dynamic Adjustment of Serialization Order for Real-Time Database Systems," Proc. of 14th IEEE Real-Time Systems Symposium, pp. 66-75, 1993. [16] Lee, V. C. S., Lam, K. Y., and Tsang, W. H., “Transaction Processing in Wireless Distributed Real-time Database Systems,” Proc. of the 10th Euromicro Workshop on Real Time Systems, pp. 214-220, Berlin, June, 1998. [17] Lee, V. C. S., Lam, K. Y., and Kao, B., “Priority Scheduling of Transactions in Distributed Real-time Databases,” Real-time Systems, vol. 16, no. 1, pp. 31-62, 1999. [18] Pitoura, E., and Bhargava, B., “Building Information Systems for Mobile Environments,” Proc. of the third international conference on Information and knowledge management, pp. 371-378, 1994. [19] Pitoura, E., “Supporting Read-Only Transactions in Wireless Broadcasting,” Proc. of the DEXA98 International Workshop on Mobility in Databases and Distributed Systems, pp. 428-433, 1998.
25 Response Time (10^6 bit-times)
[20] Pitoura, E., and Chrysanthis, P. K., “Scalable Processing of Read-Only Transactions in Broadcast Push,” Proc. of the 19th IEEE International Conference on Distributed Computing System, 1999. [21] Shanmugasundaram, J., Nithrakashyap, A., Padhye, J., Sivasankaran, R., Xiong, M., and Ramamritham, K., “Transaction Processing in Broadcast Disk Environments,” Advanced Transaction Models and Architectures, Jajodia, S., and Kerschberg, L., editors, Kluwer, Boston, pp. 321-338, 1997. [22] Shanmugasundaram, J., Nithrakashyap, A., Sivasankaran, R., and Ramamritham, K., “Efficient Concurrency Control for Broadcast Environments,” ACM SIGMOD International Conference on Management of Data, 1999. [23] Stankovic, J. A., Son, S. H., and Hansson, J., “Misconceptions About Real-Time Databases,” Computer, vol. 32, no. 6, pp. 29-37, 1999. [24] Zdonik, S., Alonso, R., Franklin, M., and Acharya, S., “Are Disks in the Air Just Pie in the Sky,” Proc. of the Workshop of Mobile Computing Systems and Applications, California, 1994.
BCC-FV BCC-TI
20
15
10
5
0 1
2
3
4
5
6
7
8
9
Mobile Transaction Length
Figure 3: Transaction Response Time vs. Mobile Transaction Length
1 6%
20% 18%
B C C -F V B C C -TI
1 4%
B C C -F V B C C -TI
16%
1 2%
M is s Ra te
M iss Rate
14% 1 0% 8% 6%
12% 10% 8% 6%
4%
4% 2% 2% 0% 1
2
3
4
5
6
7
8
0%
9
2
Mobile Transaction Length
Figure 1: Miss Rate vs. Mobile Transaction Length
Figure 4: Miss Rate vs. Server Transaction Arrival Rate
2 .5
12% B C C -F V B C C -TI
2
B C C -F V B C C -TI
10% 8%
1 .5
M iss Rate
R estart R ate
4 6 8 10 12 14 16 18 Serv er Tran sac tio n A rriv a l R ate (10^-6 tx pe r b it-tim e)
1
6% 4%
0 .5
2% 0 1
2
3
4
5
6
7
8
9
M o bile T ran sac tio n Le ng th
Figure 2: Restart Rate vs. Mobile Transaction Length
0% 2
4
6
8 10 12 14 Data Object Size (kBytes)
16
18
Figure 5: Miss Rate vs. Data Object Size
20
