Reading Temporally Consistent Data in Broadcast Disks

Transcription

1 Reading Temporally Consistent Data in Broadcast Disks Victor C.S. Lee Joseph K. Ng Jo Y. P. Chong Kwok-wa Lam Department of Computer Science,City University of Hong Kong 83 Tat Chee Avenue, Kowloon, Hong Kong Department of Computer Science, Hong Kong Baptist University Kowloon Tong, Hong Kong In this paper, we study the performance and impact of maintaining temporal consistency on a recently proposed concurrency control protocol for processing transactions in broadcast environments. This protocol offers autonomy between mobile clients and the server such that mobile clients can read consistent data off the air without contacting the server. However, most of the existing mobile computing applications, such as information dispersal systems for stock prices and weather information, are comprised of real-time read only transactions. In order to deliver timely and useful results, real-time transactions must read temporal consistent data in addition to completing the execution before their deadlines. A number of approaches to maintaining temporal consistency are studied through a series of simulation experiments. Results show that taking advantage of data semantics and temporal consistency requirement can improve the performance of mobile read only transactions in broadcast environments. I. Introduction Nowadays, millions of users are carrying some kind of portable computing devices that use a wireless interface to access the worldwide information network for business or personal use. In most of the existing mobile computing applications, such as information dispersal systems for stock prices and weather information, there are time constraints for both transactions and data. This means that data will become invalid as time passes. In order to reflect the current status of real-world objects, such data must be updated periodically. At the same time, real-time transactions must read temporally consistent data in order to generate correct results. Hence, transactions must complete their executions by their deadlines, and the data they read must be sufficiently fresh. Temporal consistency of data can be defined in terms of the age of the data and the dispersion of ages among data. The age of a data object describes how up-to-date its value is. The dispersion of two data objects is the difference between their ages. Data objects are temporally The work described in this paper was substantially supported by a grant from the Research Grants Council of the Hong Kong Special Administrative Region, China [Project No. CityU 1204/03E]. This paper is an extended version of the paper Maintaining Temporal Consistency in Broadcast Environments that appeared in the 2004 IEEE International Conference on Mobile Data Management. consistent if their ages and dispersions are sufficiently small to meet the requirement of the application. In addition, the temporal constraints of data can be described by the data deadline. Data deadline tells when the validity of a data object will expire. For a transaction to commit and generate correct results, both the transaction deadline and data deadline must be satisfied. But it is always difficult to maintain the temporal consistency due to the following reasons [11]: A transient overload may cause transactions to miss their deadlines. Data values may become out of date when they are not updated in time. Preemption may cause the data read by transactions to become temporally inconsistent. Concurrency control must be used to ensure data consistency, but it may cause temporal data inconsistency. Temporal consistency is even more difficult to maintain in broadcast environment [1]. In broadcast environments, it takes a longer time for the most recent data versions to reach at the mobile clients and the mobile clients also need to wait for the broadcast of the requested data objects. Therefore, it may be more difficult for transactions to commit before the Mobile Computing and Communications Review, Volume 8, Number 3 57

2 validity of their data objects expires. In this paper, we will study the performance of maintaining temporal consistency with timestamp ordering concurrency control in broadcast environments [6]. In particular, we will study the performance of versioning and time validity interval for a real-time mobile transaction processing system. II. Related Works There are many related works in maintaining temporal consistency in real-time database systems [5] [12] [11]. However, there is not much attention on this aspect in mobile computing environments, though there are a few works on transaction processing in broadcast environments [6] [7] [8] [10]. In particular, there is one recent pioneer work on proposing various forms of temporal and semantic coherency in broadcast environments [9]. It provides a solid theoretical basis for future research works on the area. Recently, in view of the increasing demand for realtime data services such as sensor data fusion, web information services, and online trading, Kang, Son, and Stankovic [5] proposed a differentiated real-time data service framework, Diff-Real for e-commerce applications. They pointed out that transaction timeliness and data freshness requirements could conflict with each other. By applying a number of sophisticated mechanisms including feedback and admission control, their experimental results showed that specified QoS in terms of transaction deadline miss ratio and data freshness can be achieved in the presence of unpredictable workloads and access patterns in Diff- Real. Xiong et al [12] introduced the concept of datadeadline that is a deadline assigned to a transaction to reflect the temporal constraints of the data accessed by the transaction. In this study, temporal consistency is defined in terms of the validity interval of a version of temporal data object, after which the data version is regarded as invalid. Based on the assumption that estimates of remaining transaction execution time and response time are available, two sophisticated forced wait policies are proposed. Basically, a transaction will be forced to wait for a new data version, if temporal consistency is not able to be maintained by commit time due to expiration of the validity of the old data version. Simulation results showed that the proposed data-deadline based transaction scheduling policies improve performance. The main focus of this work is on transaction scheduling in real-time databases but our work concerns more on the aspects of concurrency control. Song and Liu [11] conducted a series of comprehensive simulation experiments to evaluate the performance of concurrency control protocols in maintaining temporal consistency in hard real-time systems. They pointed out that with concurrency control in place to ensure data integrity, it is difficult to maintain temporal consistency since transactions may not be able to produce correct results on time. This is particularly true in broadcast environment. Data version that is fresh at the broadcast instant may become stale when it is read by a mobile transaction at the client side. In their work, temporal consistency is defined in terms of the age and dispersion of data. As a new data version is written, an old data version read by other transactions ages whereas the dispersion of two data versions is the difference between their ages. Data objects are temporally consistent if their ages and dispersions are sufficiently small so that the computed results based on them are considered correct. In their study, they found that the performance of the optimistic algorithm is poor in maintaining temporal consistency. However, lock-based concurrency control mechanism is inapplicable for broadcast environment [10]. Acquiring locks for every data object by transactions generated by the mobile clients incurs costly bi-directional communication between the mobile clients and the server. So, in this work, we select an optimistic concurrency control protocol, BCC- TI [6], proposed recently for broadcast environments. This protocol offers autonomy between mobile clients and the server such that mobile clients can read consistent data off the air without contacting the server. The simulation study showed that the timestamp ordering technique improves system performance by reducing the number of unnecessary transaction restarts such that the resources can be utilized more effectively. Among recent research studies on transaction processing in broadcast environments, only a few of them addressed issues related to data freshness. In [8], multiple versions of data items are broadcast to increase the concurrency of client transactions in the presence of updates. Performance results showed that the performance gain provided by multiversion broadcasting outweighed the overhead of maintaining older versions. Although the issue about data currency was introduced, this study focused on the performance of three multiversion broadcast disk organizations in terms of transaction abort rate and response time. The rest of the paper is organized as follows. In Section 3, we discuss about the Optimistic Concur- 58 Mobile Computing and Communications Review, Volume 8, Number 3

3 rency Control in broadcast environment, and then we present the three concurrency control protocols under this study. In Section 4, we describe our system model and specify the set up and parameters used. We present results and research findings from our simulation experiments in Section 5. Finally in Section 6, we provide a summary of the results for this study and discuss about our future works. III. Optimistic Concurrency Control in Broadcast Environment In optimistic concurrency control with broadcast commit (OCC-BC), a variant of OCC with forward validation, transactions can proceed without delay in the read phase [3]. When transactions wish to commit, a validation check is performed to determine whether conflict has occurred. Validation of a transaction is done against currently running transactions. This process is based on the assumption that the validating transaction is serialized before all other concurrently running transactions still in the read phase and hence, it is guaranteed to commit in OCC-BC. The write set of the validating transaction is checked if it overlaps with the read set of any active transactions. That is, if an active transaction, T, has read a data object that has been concurrently written by the validating transaction, the value of the data object used by T becomes inconsistent and T has to be restarted. For read-only transactions (ROTs) processed at mobile clients, it is not necessary to send them back to the server for validation based on the principle of forward validation. As the write set of a ROT is always empty, there is no active conflicting transaction and hence, there is no transaction needed to be aborted due to validation of ROT. In other words, if a ROT can complete its execution with no conflicts with committed transactions during its execution, it can commit autonomously at mobile client side. III.A. III.A.1. The BCC-TI protocol and Temporal Consistency The BCC-TI protocol Using OCC-BC to process ROTs at mobile clients, it is assumed that transactions committed at the server always precede concurrently active ROTs in the serialization order. However, this assumption is too strict and can incur unnecessary transaction restarts. Recently, a new protocol called broadcast concurrency control using timestamp interval (BCC-TI) is proposed in which the assumption is relaxed with the aim to reduce unnecessary restarts in broadcast environments [6]. The basic idea of the BCC-TI protocol is to dynamically adjust the position of the ROTs in the current serialization order by recording a timestamp interval associated with each active ROT. Each ROT has a timestamp interval. Data conflict is checked by the shut out of timestamp interval. Whenever a ROT reads a data object from the broadcast disk, the lower bound of the timestamp interval will be adjusted to reflect the serialization order induced between it and the committed update transactions that have written the data object. If the write timestamp (WTS) of the data object is greater than the lower bound, the lower bound will be set to this WTS. If the timestamp interval shuts out, i.e. lower bound upper bound, a non-serializable execution performed by the ROT is detected and the ROT will be restarted. To check the data conflict with respect to the server transactions committed in previous broadcast cycle, ROT needs to be checked against the control information broadcast at the beginning of each broadcast cycle. The control information in the current broadcast cycle stores the information of the data objects, which are updated during previous broadcast cycle. To determine whether a ROT has introduced a nonserializable execution with respect to the committed update transactions, mobile clients need to adjust the upper bound of the timestamp interval. If the updated write timestamp (WTS) of the data object, which has been read by the ROT, is smaller than the upper bound, the upper bound will be set to this WTS. This adjustment implies that the recent write operation of the data object does not affect the old value read by the ROT in previous broadcast cycles. If the timestamp interval shuts out, i.e. lower bound upper bound, a non-serializable execution performed by the ROT is detected and the ROT will be restarted. III.A.2. Temporal Data In a database system, in particular, a real-time database, data objects can be classified into temporal and non-temporal. The values of temporal data objects may change continuously to reflect the status of real world objects such as traffic condition. In a traffic monitoring system, updated road conditions periodically sampled by a sensor network are installed into a database system for broadcasting to a large population of road users for close monitoring of the traffic condition and timely alert signals such as traffic jam for immediate attention. Such values of temporal data objects become invalid with the passage of time and have to be updated periodically by update Mobile Computing and Communications Review, Volume 8, Number 3 59

4 transactions to reflect the current status. On the other hand, there is no time constraint for non-temporal data objects, though they may be written aperiodically by server transactions submitted by applications to the server. Server transactions can read temporal data objects and read or write non-temporal data objects. Such database systems require temporal consistency in addition to logical consistency in order to produce correct results. III.A.3. Temporal Consistency - Versioning Temporal consistency can be defined in terms of the age of the data and the dispersion of ages of the data [11]. In real-time databases, temporal data objects are updated periodically by update transactions. When they are updated, a new image version is written and the old value of the image read by other transactions ages. The age of an image version at time t in the ith period after its valid time is i-1. The shorter is the period of the update transaction, the faster the image versions age. The dispersion of two temporal data objects is the difference between their ages. Let a (x) and a (y) be theagesofdataobjectsx and y at time t respectively. The dispersion of ages between x and y at t is d (x, y) = a (x) - a (y). A set Q of image versions is absolutely temporally consistent at time t if a (x) A(A 0) for any x in Q, wherea is an absolute threshold. Q is relatively temporally consistent at time t if d (x, y) R(R 0) for every two data objects x and y in Q, wherer is a relative threshold. A set of data objects is temporally inconsistent if the objects are either absolutely or relatively temporally inconsistent. The threshold values of A and R reflect the temporal requirements of the application. III.A.4. Temporal Consistency - Time validity interval () The time validity interval denotes the period in which the data object is considered to be temporally consistent [12]. When a new value of a temporal data object is created, it is valid for a period of time. After this valid period of time, the temporal data object value is no longer correct. This period is determined by the requirement of the application. Usually, update transactions are generated such that new values are installed into the database by the end of the time validity interval. Let vi (x ) and vi (x ) to be the beginning of the validity interval and the end of the validity interval of the ith version of data object x respectively. The ith version of data object x is temporally consistent at time t if and only if vi (x ) t vi (x ). III.B. Concurrency Control Protocols at Mobile Clients With a brief introduction in the previous section highlighting the optimistic concurrency control in broadcast environment and the definitions of temporal consistency based on versioning and time validity interval, we will present the three concurrency control protocols that will be investigating in our study. III.B.1. In the client s view, temporal data objects are not discriminated from other data objects. The lower bound value of the timestamp interval is adjusted when a ROT reads a data object in a broadcast cycle. On the other hand, the upper bound value of the timestamp interval is adjusted when a ROT consults the control information. A ROT will be restarted if the timestamp intervals shut out. Figure 1 shows the pseudo-code for the BCC-TI protocol at the mobile client in our study. For detailed operations of the timestamp intervals adjustment and correctness proof, readers may refer to [6]. FOR each operation DO IF data object already past in the current broadcast cycle THEN wait for the next broadcast cycle check control information Read data object IF transaction deadline is missed THEN terminate := TRUE commit := TRUE III.B.2. Figure 1: Pseudo-code for BCC-TI BCC-TI with Versioning Temporal data objects are associated with version numbers. Whenever a temporal data object is updated, a new version, as well as a new version number, is generated. Temporal data objects are handled differently with other data objects at mobile clients. Whenever a temporal data object is read, its version number is stored. These stored version numbers will be used to calculate the absolute ages and the relative ages 60 Mobile Computing and Communications Review, Volume 8, Number 3

5 when the client performs checking against the control information in every broadcast cycle. If the absolute age of any temporal data object exceeds the absolute threshold or the age difference between any pair of temporal data objects exceeds the relative threshold, the ROT will be restarted. There will be no adjustment of timestamp interval for temporal data objects and non-temporal data objects are handled using the BCC-TI protocol. Figure 2 shows the pseudo-code for the BCC-TI protocol with versioning for checking temporal consistency among temporal data objects. FOR each operation DO IF data object already past in the current broadcast cycle THEN wait for the next broadcast cycle check control information IF absolute or relative threshold is exceeded THEN Read data object IF transaction deadline is missed THEN terminate := TRUE commit := TRUE III.B.3. Figure 2: Pseudo-code for versioning BCC-TI with Time Validity Interval Same as versioning, temporal data objects are handled differently with other data objects at mobile clients. Each temporal data object is associated with a time validity interval. Each mobile ROT is associated with a data deadline after which the transaction is considered to be temporally inconsistent. Temporal data objects are read together with an expiration time (end time of the time validity interval). If the expiration time is earlier than the current data deadline, the data deadline will be set to this expiration time. Then, in each operation of the ROT, the data deadline is checked to ensure temporal data consistency. If the data deadline is missed, the ROT will be restarted. Again there is no adjustment of timestamp interval for temporal data objects and non-temporal objects are handled using the BCC-TI protocol. Figure 3 shows the pseudocode for the BCC-TI protocol with time validity interval for checking the temporal consistency among temporal data objects. FOR each operation DO IF data object already past in the current broadcast cycle THEN wait for the next broadcast cycle check control information Read data object IF data deadline is missed THEN IF transaction deadline is missed THEN terminate := TRUE commit := TRUE IV. IV.A. Figure 3: Pseudo-code for Simulation Experiments Model Description Figure 4 shows the model for our simulation experiments [6]. It consists of a database with temporal and non-temporal data objects, a server, a broadcast disk and a number of mobile clients. IV.A.1. Database The data objects in the database are divided into nontemporal data objects and temporal data objects. Each of them is associated with a write timestamp (WTS), which is the last update time of the data object. Temporal data objects are only updated by periodic update transactions. That means that other server transactions will not update the values of these temporal data objects. All temporal data objects are updated periodically asynchronously. A version number or an expiration time is associated with each temporal data object for the versioning and the time validity interval protocols respectively. Version number denotes the ith version of the temporal data object. IV.A.2. Server There are two types of transactions in the server: update transactions and server transactions. Update transactions model the periodic sampling and updating of the temporal data objects. They periodically install sampled values of real-world objects into the database. These update transactions are write-only and do not read any data object. Hence, their write operations are disjoint from each other and from the write sets of server transactions. When an update Mobile Computing and Communications Review, Volume 8, Number 3 61

6 Update Transaction Update Manager Temporal Nontemporal Broadcast Disk Manager Broadcast Disk Read-Only Transaction Manager Server Transaction Server Transaction Manager Server Wireless Network Client Devices Figure 4: The simulation model transaction writes a temporal data object in each period, it creates a new version of the temporal data object. In this case, no concurrency control is required for these temporal data objects. Server transactions can read all data objects but they can only write non-temporal data objects. The OCC-BC protocol is adopted for concurrency control. When server transactions come to validation phase, they are allowed to commit and all the conflicting active server transactions are restarted. Write operations on temporal or non-temporal data objects will update their WTSs which will be included in the control information and broadcast in the following broadcast cycle. IV.A.3. Mobile Clients Each mobile client generates ROTs, one after the other. In the current model, client side caching is not considered and can be reserved for future work. So, without caching, for each read operation, the client needs to wait for the requested data object to be broadcast. If the data object is missed (already broadcast) in the current broadcast cycle, the client has to wait for the same data object in the next cycle. Before reading any data object in a broadcast cycle, the client has to consult the control information to perform a partial validation. IV.A.4. Broadcast Disks In each broadcast cycle, the server broadcasts the values of all data objects and the control information in the form of a single flat broadcast disk structure [1] [4]. The control information is broadcast first, followed by the latest values of all data objects at the start of a broadcast cycle. IV.B. Experiment Set-up and System Parameters As mentioned in previous sections and referring to Figure 4, the simulation model consists of a server, a number of mobile clients and a broadcast disk. Table 1 lists the baseline settings for the simulation experiments. The database at the server contains 300 data objects in which 30 of them are temporal data objects. A small database is used to model hot spot in which data objects are frequently accessed by transactions. In the system, there are three types of transactions. They are mobile transactions submitted by the mobile clients, server transactions processed at the server, and update transactions for installing the latest values of the temporal objects in the database at the server. Mobile transactions are read only and server transactions consist of both read and write operations. For data objects accessed by mobile and server transactions, 40 are temporal data objects and 60 are non-temporal data objects. Each data object in a class has an equal chance of being accessed by an operation. Each temporal data object is updated asynchronously at a fixed interval by an update transaction. Transactions are generated at the transaction generator and are lined up in the CPU queue according to the scheduling discipline. When the CPU is available, the transaction at the front of the CPU queue will be submitted to the CPU for processing. To read a data object, transactions need to line up in the disk queue for data access. The transactions will repeat these steps until all operations are processed. During each operation, transactions will check if they have 62 Mobile Computing and Communications Review, Volume 8, Number 3

7 missed the transaction deadlines. For versioning and time validity interval, temporal data consistency will be checked as well. If a transaction can commit, it will line up in the disk queue again for installing the pre-written values into the database. All active transactions will be checked to see if they have accessed the data objects written by the validating transaction. Those active transactions that have read the data objects will be restarted. The ROTs generated by mobile clients read data objects from the broadcast disk. In each operation, they will listen and wait for the requested data objects to be broadcast. When a data object is read, they will adjust their lower bound of timestamp intervals to reflect their position in the serialization order. Version numbers and the end of validity intervals will be recorded in the case of versioning and time validity interval respectively. When control information is received, they will adjust their upper bound of timestamp intervals as well. Ages of temporal data objects read by ROTs will be checked in the case of versioning. In each operation, transaction deadline is checked. Data deadline will be checked too in case of time validity interval. If ROTs can complete the last operation without missing the transaction deadline, they can commit autonomously. Transactions are processed until either they are committed or the transaction deadline is missed. The deadline of a transaction d(t) arrived at a(t) with predicted execution time p(t) is assigned by the following formula. d(t)=a(t) + slack factor * p(t) (1) where p(t) for mobile transactions = broadcast cycle time transaction length + client inter-operation delay (transaction length - 1),and p(t) for server transactions = (disk service time + CPU service time) transaction length. The transaction length is the number of operations in a transaction. There are two priority levels for transaction scheduling at the server. Update transactions are assigned with a higher priority level than that of server transactions. Among update transactions, they are scheduled in First-Come-First-Serve (FCFS) manner. Among server transactions, they are scheduled in Earliest-Deadline-First (EDF) manner. The time unit is in K bit-times, the time to transmit 1 K bits in broadcast environments. For a broadcast bandwidth of 64kbps, 1 M bit-times is equivalent to approximately 15 s and the mean inter-operation delay and the mean inter-transaction delay are 1 s and 2 s respectively. At the start of each broadcast cycle, the server fills the broadcast disk with control information followed by all data objects in the database. The control information consists of the timestamps and write sets of the committed server transactions and update transactions during the last broadcast cycle. Version numbers of temporal data objects are contained as well. The broadcast of data objects contains the values and the write timestamps of the data objects. The current version numbers and the ends of time validity interval are broadcast along with the temporal data objects. IV.C. Performance Measures The performance of the protocols under this study is compared by a number of performance measures. The miss rate is the percentage of transactions missing their deadlines. A transaction meeting its deadline may experience restart due to data conflicts with other active transactions or reading temporally inconsistent data. Another performance measure is the restart rate, which can better reflect the behavior of the protocols. The restart rate is the average number of restarts before a transaction leaves the system. A transaction leaves the system when it commits upon successful completion of execution or aborts due to missing its deadline. The transaction response time is the time elapsed when a transaction leaves the system since a mobile client submitted the transaction. Since we did not consider caching at mobile clients in this study, a transaction requesting for a data object has to wait until the data object is broadcast by the server. If the data object is already broadcast in the current cycle, the transaction needs to wait for the next cycle. If a transaction is restarted due to data conflicts or temporal inconsistency, a long response time will result. In order to measure the freshness of temporal data objects read by transactions, we recorded the mean maximum age, which is the average of the largest age of the temporal data objects read by transactions. A mean maximum age of zero value means that transactions always read the most recent data version. V. Results and Discussions In this series of simulation experiments, we studied four protocols, namely, Versioning,, and Datacycle [2]. Similar to, Datacycle does not differentiate between temporal and non-temporal data objects. However, there is no dynamic adjustment of serialization order in Datacycle. In Datacycle, a read-only transaction will be restarted if it finds from the control information that some up- Mobile Computing and Communications Review, Volume 8, Number 3 63

8 Table 1: Baseline settings for the simulation experiments Parameter Value Mobile clients Transaction length (number of read operations) 5 Mean inter-operation delay 65,536 bit-times (exponentially distributed) Mean inter-transaction delay 131,072 bit-times (exponentially distributed) Slack factor (uniformly distributed) Concurrency control protocol BCC-TI Probability of accessing temporal objects 0.4 Number of Clients 10 Server Transaction length (number of operations) 8 Transaction arrival rate 1 per 100K bit-times CPU service time K bit-times (15 ms) Disk service time K bit-times (25 ms) Probability of accessing temporal data objects 0.4 Probability of writing non-temporal data objects 0.8 Total number of data objects in database 300 Number of temporal objects in database 30 Size of data objects (including object ID) 8 K bits Timestamp size 8 bits Concurrency control protocol OCC-BC Priority scheduling Higher Priority First Period of temporal objects 3,000-7,000K bit-times (uniformly distributed) date transactions that committed in the last broadcast cycle have written onto any data object that the readonly transaction has read. For Versioning, different threshold values are used. When the threshold value is 0, any update of a temporal data object will lead to violation of temporal consistency and the transaction that has read the old version of the temporal data object will be restarted accordingly. In Figure 5 and 6, the miss rate and restart rate of all protocols increase when the length of mobile transactions increases. The length of mobile transactions is defined as the number of read operations in a mobile transaction. To read more data objects, a mobile transaction may span a larger number of broadcast cycles. As a result, it is more likely for it to miss the deadline and more difficult for it to meet the deadline after restart. In addition, the prolonged execution time also increases the chances of having data conflicts with server transactions because more server transactions will be executed concurrently with the mobile transaction. The performance of Datacycle is the worst because transactions will be restarted when any (temporal or non-temporal) data objects they have read in previous broadcast cycles are updated and found in the control information. has a better performance than Datacycle because dynamic adjustment of serialization order mechanism is applied to non-temporal data objects. Any update of non-temporal data objects read by a mobile transaction may not cause a restart as far as the timestamp intervals do not shut out. Versioning 1 and have even better performance than as their temporal requirements are less stringent. However, the amount of improvement from to narrows as compared with that from to. On the other hand, is the most sensitive to the validity of temporal data objects. Whenever the data deadline of any temporal data objects that a transaction has read in previous broadcast cycles is missed, the transaction will be restarted. Therefore, the miss rate of is high. The most interesting observation is the performance of the protocol relative to the other protocols. We find that its performance is in between that of and. Even though ignores temporal consistency, from Figure 5 and 7, its performance in terms of miss rate and response time outperforms. However, there may be some cost to pay for the good miss rate. In order to measure the trade-off between meeting transaction deadlines and maintaining data freshness, 64 Mobile Computing and Communications Review, Volume 8, Number 3

9 Miss Rate Datacycle Restart Rate Datacycle Figure 5: Miss rate versus mobile transaction length Figure 6: Restart rate versus mobile transaction length Response Time (10^6 bit-times) Datacycle Mean Maximum Age Datacycle Figure 7: Response time versus mobile transaction length Figure 8: Mean maximum age versus mobile transaction length Figure 8 shows the mean maximum age of temporal data objects read by transactions in different protocols. gets the best data freshness. All temporal data objects read by transactions are the most recent version to make the values of mean maximum age zero. and Datacycle get similar performance when the length of mobile transactions is short. As transaction length increases, outperforms Datacycle. Again, the most interesting finding is the performance of. Results show that its performance is close to that of. That is, even though ignores temporal consistency, it maintains a certain level of temporal consistency that is similar to that of. In other words, on the average, the value of temporal data objects read by transactions under is one version older than the most recent one. To have a better understanding on the causes of transaction restarts, the restart rate is further broken down into two categories: due to data inconsistency and due to temporal inconsistency. Figure 9 shows the restart rate due to data inconsistency and Figure 10 shows the restart rate due to temporal inconsistency. In Figure 9, although does not differentiate between temporal and non-temporal data objects, the timestamp interval adjustment mechanism is sensitive to updates of temporal data objects and results in transaction restarts due to data inconsistency. In Figure 10, we observe that restart rate due to temporal inconsistency rises sharply as the length of mobile transactions increases when data freshness is strictly maintained by and. By relaxing the temporal requirement in and Versioning 2, restart rate due to temporal inconsistency can be greatly reduced. Figures 11 and 12 show the proportion of transaction restarts due to data inconsistency and temporal inconsistency respectively. Note that the two figures are compliment to each other. From these two figures, we can recognize which category of inconsistency dominates the performance of the protocols and the significance of relaxing the temporal requirement in improving the system performance. Mobile Computing and Communications Review, Volume 8, Number 3 65

10 Restart Rate due to Data Inconsistency Restart Rate due to Temporal Inconsistency Figure 9: Restart rate due to data inconsistency Figure 10: Restart rate due to temporal inconsistency Proportion of Restarts Due to Data Inconsistency Proportion of Restarts Due to Temporal Inconsistency Figure 11: Proportion of restarts due to data inconsistency VI. Summary and Future Works Few studies consider temporal consistency in broadcast environments, though many mobile computing applications such as information dispersal systems do broadcast temporal data objects. We have evaluated the performance of a number of approaches to maintaining temporal consistency in broadcast environments. For versioning, a set of data objects are regarded as temporally inconsistent if their ages or dispersion of ages violate the temporal requirements of the application, which are specified in terms of the absolute and relative threshold. For, there is a data deadline associated with each data object. A transaction accessing a data object with an expired data deadline has to be restarted. In addition, we adopted a recently proposed concurrency control protocol for processing mobile transactions. By applying dynamic adjustment of serialization order, unnecessary transaction restarts can be reduced significantly. The simulation results showed that taking advantage of data Figure 12: Proportion of restarts due to temporal inconsistency semantics and temporal consistency requirement can improve the system performance. In particular, the performance in terms of miss rate, restart rate and response time can be significantly improved if a less stringent temporal consistency requirement is applied. Moreover, there is one interesting finding. For Pure BCC-TI, which does not differentiate between temporal and non-temporal data objects, its performance in terms of mean maximum age is similar to that of. Simply speaking, the value of temporal data objects read by transactions under is around one version older than the most recent one. We are going to study a more flexible approach by broadcasting multiple versions of data objects [8]. According to the quality of service (QoS) requirement of applications, mobile clients can select between a lower transaction miss rate and a higher data freshness by choosing different versions of data objects in the broadcast disks. 66 Mobile Computing and Communications Review, Volume 8, Number 3

11 References [1] Swarup Acharya, Rafael Alonso, Michael Franklin, and Stanley Zdonik. Broadcast disks: data management for asymmetric communication environments. In Proceedings of the 1995 ACM SIGMOD international conference on Management of data, pages ACM Press, [2] T.F.Bowen,G.Gopal,G.Herman,T.Hickey, K. C. Lee, W. H. Mansfield, J. Raitz, and A. Weinrib. The datacycle architecture. Commun. ACM, 35(12):71 81, [3] Jayant R. Haritsa, Michael J. Carey, and Miron Livny. On being optimistic about real-time constraints. In Proceedings of the ninth ACM SIGACT-SIGMOD-SIGART symposium on Principles of database systems, pages ACM Press, for broadcast environments. In Proceedings of the 1999 ACM SIGMOD international conference on Management of data, pages ACM Press, [11] Xiaohui (Carol) Song and Jane W. S. Liu. Maintaining temporal consistency: Pessimistic vs. optimistic concurrency control. IEEE Transactions on Knowledge and Data Engineering, 7(5): , [12] Ming Xiong and Krithi Ramamritham. Scheduling transactions with temporal constraints. IEEE Transactions on Knowledge and Data Engineering, 14(5): , [4] Quinglong Hu, Wang-Chien Lee, and Dik Lun Lee. Indexing techniques for wireless data broadcast under data clustering and scheduling. In Proceedings of the eighth international conference on Information and knowledge management, pages ACM Press, [5] Kyoung-Don Kang, Sang H. Son, and John A. Stankovic. Differentiated real-time data services for e-commerce applications. Electronic Commerce Research, 3(1-2): , [6] Victor C. S. Lee, Kwok-Wa Lam, and Sang H. Son. Concurrency control using timestamp ordering in broadcast environments. The Computer Journal, 45(4): , [7] Sanjay Kumar Madria and Mukesh Mohania. Mobile data and transaction management. Inf. Sci. Inf. Comput. Sci., 141(3-4): , [8] Evaggelia Pitoura and Panos K. Chrysanthis. Multiversion data broadcast. IEEE Trans. Comput., 51(10): , [9] Evaggelia Pitoura, Panos K. Chrysanthis, and Krithi Ramamritham. Characterizing the temporal and semantic coherency of broadcast-based data dissemination. In Proceedings of the 9th International Conference on Database Theory, pages Springer-Verlag, [10] Jayavel Shanmugasundaram and Arvind Nithrakashyap. Efficient concurrency control Mobile Computing and Communications Review, Volume 8, Number 3 67