Approaches for Scheduling of Triggered ... - Semantic Scholar

1 downloads 0 Views 49KB Size Report
closest deadline will be assigned with the highest priority. [14]. Other commonly used scheduling algorithms are the rate monotonic analysis (RMA) [14] and the ...
Approaches for Scheduling of Triggered Transactions in Real-time Active Database Systems Kam-yiu Lam and Tony S.H. Lee Department of Computer Science City University of Hong Kong 83 Tat Chee Avenue, Kowloon HONG KONG Email: [email protected] Abstract A real-time active database system (RTADBS) has to provide capabilities for timely trigger of timeconstrained transactions and at the same time to process them, concurrently with others transactions, in a real-time manner. Mostly, triggered transactions are critical transactions. It is highly important to commit them. Committing a triggered transaction requires meeting the deadline constraints of its triggering transaction and also the data deadlines of its accessed temporal data objects. However, the generations of triggered transactions decrease the predictability of the system as they increase the system workload and the probability of data conflicts. In this paper, we propose different approaches for assigning deadlines and priorities to the triggered transactions with the objectives to satisfy the timing requirements of the triggered transactions especially for the more critical ones. The performance of the new approaches and their relationships with different coupling modes have been studied using simulation. Keywords: real-time active database systems, priority and deadline assignment, scheduling, coupling modes, triggering of transactions

1

Introduction

Real-time Database Systems (RTDBS) are defined as database systems where transactions have explicit constraints, called deadlines, on their completion times [9]. Missing the deadlines can severely affect the usefulness of completing the transactions and may result in disasters if the transactions are hard real-time. Most of the previous work on RTDBS are concentrated on the design of real-time scheduling algorithms and concurrency control protocols which aim at completing the transactions before their deadlines and maintaining database consistency [18]. In order to meet the deadlines, different priority scheduling algorithms have been proposed to schedule the time-constrained transactions to use the CPU based on their criticality and timing constraints. One of the mostly used scheduling algorithms in RTDBS is the earliest deadline first (EDF) in which the transaction with the closest deadline will be assigned with the highest priority [14]. Other commonly used scheduling algorithms are the

rate monotonic analysis (RMA) [14] and the effective deadline (ED). The RMA is a static scheduling algorithm for the scheduling of periodic hard real-time transactions in which the required data objects and the expected execution time of the transactions are known in advance. A higher priority is assigned to the transaction with a shorter period of generation. The ED is a dynamic priority scheduling algorithm [2]. The priority of a transaction is defined as the inverse of the difference between the deadline and its expected execution time. It is suitable to the systems where the expected execution times of the transactions are predictable. In the last decade, a number of concurrency control protocols have been proposed for RTDBS [18]. The major problem is priority inversion which is the situation where a higher priority transaction is blocked by a lower priority transaction due to data conflict. Some of the proposals are High Priority Two Phase Locking (HP-2PL) [1] and Optimistic Concurrency Control with Broadcast Commit (OCC-BC) [12]. In HP-2PL, if the priority of the lock requesting transaction is higher than the priority of the lock holding transaction, the lock holding transaction will be restarted. In OCC-BC, the execution of a transaction is divided into three phases: read, validation and write. Data conflicts are resolved at the validation phase. The transactions, which are conflicting with the validating transaction, will be restarted. Previous studies have shown that the OCC-BC generally performs better than HP-2PL due to the greater number of fruitful restarts [12]. In order to provide a better solution, in recent years there is a strong move towards integrating the technologies in RTDBS with the technologies in active database systems [3, 4, 5, 13, 10, 16] as both of them are for applications with similar requirements. They have to handle transactions and data in a real-time manner. The integrated systems are called real-time active database systems (RTADBS). Active database systems support different mechanisms for triggering of transactions to react to the critical events occurred in the external environment [11]. The newly created transaction is called triggered transaction. However, active database systems are lacking mechanisms to guarantee that the triggered transactions can be completed before their deadlines. Their processing is “passive” even though their generations are “active”. It is unpredictable and

completely dependent on how the system schedules them. On the other hand, RTDBS supplements the deficiencies of the unpredictability in active database systems by using different scheduling algorithms to minimize the number of deadline missing. The integration of real-time databases with active databases creates new scheduling problems. Triggering of transactions represent the generations of actions (in the form of triggered transactions) to respond to the occurrences of critical events in the external environment. It is highly important to commit these transactions. If the critical events are beneficial, missing the deadline of a triggered transaction means the loss of a good opportunity. If the occurred events are harmful, missing the deadline may result in disasters. Triggering of transactions decreases the predictability of the system as the triggered transactions increase the system workload and the probability of data conflicts suddenly. Consequently, it will affect the performance of the whole system. In this paper, we study the impact of triggering of transactions on the system performance and introduce new approaches to assign deadlines and priorities to triggered transactions in a RTADBS in which the optimistic method with broadcast commit (OCC-BC) is used for concurrency control. The objective of the proposed approaches is to commit more triggered transactions especially the more important ones. The organization of the remainder of the paper is as follows. Section 2 discusses of the important issues in the design of RTADBS. Section 3 discusses problems due to triggering of transactions. Section introduces our proposed approaches for deadline and priority assignments to the triggered transactions. Section 5 describes the RTADBS model and the results of the simulation experiments. Section 6 is the Conclusions of the paper.

2

Design Issues of RTADBS

2.1 Temporal Data and Updates An important characteristic of real-time active database applications is that they have to monitor and respond to the changes in the external environment in a real-time manner. In these systems, some data objects, called temporal data objects, are used to record the status of the objects in the external environment [15]. Some of the examples are the prices of the stocks, the temperature of a nuclear power plant and the position of an air flight. The values of these data objects may change rapidly. If their current values are deviated from the actual status of the objects, they are called invalid. Invalid data objects are considered to be useless as the information contained is not true. Whenever a transaction accesses an invalid data object, the transaction has to be aborted. The validity of a temporal data object can be defined by its absolute validity interval (avi). The data object is invalid, if the current time is greater than the sum of the avi and the commit time of the last update. Validity of temporal data objects can be maintained by timely

installation of updates which capture the up-to-date status of the objects in the external environment. The scheduling of updates can affect the performance of the systems. If higher priorities are assigned to the updates, the validity of the temporal data objects can be maintained but the scheduling of the transactions will be affected. If reversed, the transactions may have a high chance of accessing invalid temporal data objects. In [2], the on demand approach has been suggested to solve the above problem.

2.2 Triggering of Transactions in RTADBS Usually, the definitions of the conditions for triggering of transactions involve the examination of the values of some temporal data objects. Some examples are the price of a particular stock is higher than a certain value and the position of a flight is too close to an object. Whenever a condition is satisfied, an action, in the form of triggered transaction, will be generated and the original transaction is called triggering transaction. The relationship between the triggered and triggering transactions is defined by coupling mode. Two common coupling modes are the deferred and the 1 immediate coupling modes [9] . Under the deferred coupling mode, the creation and the execution of a triggered transaction is started only after the completion of the triggering transaction. Under the immediate coupling mode, once a condition is satisfied, the triggered transaction will be created and executed “immediately”. At the same time, the execution of the triggering transaction will be suspended until the completion of the triggered transaction. Thus, the processing ordering of the triggered transaction and the remaining part of the triggering transaction is just the reverse of that under the deferred coupling mode. The coupling mode also defines the commit dependency of the triggered and triggering transactions. If the triggered transaction is defined as a sub-transaction of the triggering transaction, the triggered transaction cannot commit even though it is completed as it is commit dependent on the triggering transaction. It has to wait until the commitment of the triggering transaction. In this paper, we assume that all the triggered transactions are sub-transactions of the triggering transactions and they have a commit dependency on each other.

3

Impact of Triggering of Transactions

Although to commit a triggered transaction is highly important, not much work has been done on how to assign deadlines and priorities to triggered transactions. Similar to the triggering transactions, the commitments of triggered transactions are also constrained by deadlines. Mostly the triggered transactions are assigned with the deadlines and priorities of their triggering transactions as 1

Other common coupling modes are detached dependent and independent.

they have to be completed before the deadlines of the triggering transactions [17]. However, simply using the deadlines of the triggering transactions may not be able to commit the triggered transactions due to the unpredictability introduced by triggering of transactions. Triggering of transactions are unpredictable events and are resulted from the state of the database which is highly dynamic. Thus, the system cannot anticipate the additional resource requirements of the triggered transactions. If the system schedules the triggered transactions in the same way as the other transactions, which do not trigger any transactions, the probability to commit the triggered transactions may be very low. This is especially true if the triggering is occurred at the later stage of the execution of a transaction. The situation will be different under different coupling modes. For example, under the deferred coupling mode, if the triggering transaction cannot be completed earlier, it is more possible that the triggered transaction will miss its deadline because of insufficient slack time for its execution. The triggered transaction may already miss its deadline even before the start of its execution. Under the immediate coupling mode, although the triggered transactions start their executions earlier and will have higher probability to complete before the deadlines, they still have to wait for the completion of the triggering transactions. Thus, the probability of missing the deadline of a triggered transaction is affected by the scheduling of the triggering transaction as missing the deadline also causes the triggered transaction to abort. Another problem is its impact on concurrency control. The probability of data conflict will be higher as the number of concurrently executing transactions will be greater. Thus, a higher cost is required to resolve the data conflicts. For example, if OCC-BC is used for concurrency control, more transaction restarts will occur due to greater number of data objects conflicts and more workload will be wasted on the restarted transactions. The restarted transactions will affect the scheduling of other transactions. Consequently, more transactions will miss their deadlines. Another problem is due to the temporal constraints of the data objects. The deadlines of the triggered transactions are also constrained by the temporal constraints of the data objects which are responsible for their triggering. If the triggered transactions cannot be committed before the data objects become invalid, they have to be aborted as the conditions for the triggering may not be true when the temporal data objects are invalid.

4

Scheduling of Triggered Transactions

4.1 Transaction Deadline Approach (TDD) To resolve the unpredictability problems due to triggering of transactions and to commit more triggered transactions, we have proposed different deadline and priority assignment approaches for triggered transactions. Since the deadline of a triggered transaction is constrained

by the deadline of the triggering transaction and the temporal constraints of the data objects accessed by it, the deadline of a triggered transaction can be defined as: Deadlinett = min(Deadlinet , TemporalD ) where Deadlinet is the deadline of the triggering transaction and TemporalD is called the data deadline of data object D. It is the time when the data object, D, becomes invalid. We call this approach the transactiondata deadline (TDD) approach as it consider both the transaction deadline and data deadline. Initially, the triggered transaction is assigned with the deadline of the triggering transaction. Whenever the triggered transaction accesses a temporal data object, its deadline is compared with the data deadline of the temporal data object. If the data deadline is closer, its deadline will be replaced by the data deadline. The purpose of the TDD approach is to make the deadlines of the triggered transactions truly reflect the urgency of the transactions. Also, with the TDD approach, the abort due to missing the data deadlines can be identified earlier so that the amount of workload wasted on those transactions can be much reduced. If the EDF is used for CPU scheduling, the priority of a triggered transaction under the TDD approach will be defined as: 1 / min(Deadlinet , TemporalD ) Thus, with the TDD approach the priority of a triggered transaction will be higher if the data deadline is tighter. Under the immediately coupling mode, a triggered transaction cannot commit even though it has been completed as it is commit dependent on its triggering transaction. If the priority of the triggering transaction is low, it is possible that a triggered transaction will miss its deadlines while it is waiting for the completion of the triggering transaction. Thus, in the application of the TDD approach under the immediately coupling mode, the priority of the triggering transaction also has to be raised up according to the triggered transaction if it is higher. Similarly, under the deferred mode once the condition for triggering is satisfied, the priority the triggering transaction will be raised up, if the priority of the triggered transaction is higher, in order to complete earlier.

4.2 Effective TDD (ETDD) Approach Including data deadline in priority assignment of the triggered transactions may not be able to reduce the number of deadline missing of triggered transactions significantly if the remaining slack times for the execution of the triggered transactions are very small. This is especially truly if the triggering occurs at the later stage of the transactions and the deadline constraints of the triggering transactions are already very tight. If the lengths of the triggered transactions are predictable, we may reserve the resources for the execution of them during the execution of the triggering transactions. One pessimistic solution is to assume that every transaction will trigger a transaction although this may not really happen. Then, the system schedules the transactions using

the ED and assumes that the lengths of the transactions are the sum of their original length plus and the length of their triggered transactions. In this way, the impact of the unpredictability due to triggering of transactions can be reduced as the required resources for processing of the triggered transactions have already been considered. This effective deadline approach can be combined with the TDD approach and the new approach is called Effective transaction-data deadline approach (ETDD). Under the ETDD approach, the assignment of priority is divided into two steps. Firstly, when a transaction is generated, its priority (Priorityt ) is defined as: Priorityt = 1/( Deadlinet - expected execution time of t - expected execution time of tt ) where Deadlinet is the deadline of the generated transaction and tt is its triggered transaction. Secondly, if the transaction really triggers a transaction, the priority of the triggered transaction will be set to be: Prioritytt = 1/ (min(Deadlinet , TemporalD ) expected execution time of tt ) At the time of triggering, the data deadline with be compared will the deadline of the triggering transaction. The smaller one will be minus by the expected execution time of the triggered transaction to obtain the effective deadline which will be used to define the priority of the triggered transaction. The purpose of ETDD is to raise up the priority of a triggered transaction according to the urgency of the transaction. Also, if it has found that the priority is a negative before the generation of the triggered transaction, the triggered transaction will be aborted immediately as it has no chance to complete before its deadline. In this way, the amount of workload wasted on the aborted triggered transactions can be further reduced.

4.3 Data State Dependent Approach The generation of a triggered transaction implies that some specific attention has to be paid to the current system status as some critical events have occurred and a response is generated, e.g., missile is coming and a defensive missile is to be created to destroy the enemy missile. Therefore, the triggered transactions are usually highly critical and are much more critical than other transactions, which do not trigger any transactions. For example, in a navigation system for robot, transactions are created periodically to detect whether there are any obstacles in front of the robot. Once it has found that there is an obstacle on its way, a reaction transaction will be triggered to stop the robot or to change its moving direction. The criticality of the detection transactions should be lower than the criticality of the reaction transactions as the existence of any reaction transactions implies that a risk is coming. On the other hand, missing the deadlines of the detection transactions is less serious as the detection transactions will find nothing in front of the robot in most of the cases. To

reflect the higher importance, higher criticality, and thus higher priorities, should be assigned to the triggered transactions comparing with the non-triggering transactions. Not only the criticality of the triggered transactions may be higher than the non-triggering transactions, the criticality amongst the triggered transactions may also be different as the result of satisfaction of some triggering conditions may have different importance. The triggered transaction in connection with an important condition should be assigned to a higher criticality. For example, in a program stock trading system, the condition to buy the stock X and Y is when their prices are lower than $10. Assuming that the new price of stock X is $9, thus a buy transaction, B1, is triggered. At the same time, the price of stock Y is $2. Thus, another buy transaction B2 is triggered to buy stock Y. To the system users, B2 is more critical than B1 as completing it can yield more profit. In this scenario, B2 should be given a higher criticality. Thus, in assigning criticality to a triggered transaction, both the criticality of the triggering transaction and the criticality resulted from the data objects, which are responsible for the triggering, have to be considered. We call this approach as the data state dependent (DSD) approach: Criticalitytt = α × Criticalityt + β × DataStateD where α and β are the weighting factors. Criticalityt is the original criticality of the triggering transaction and DataStateD is a function which defines the criticality based on the data objects which are responsible for the triggering. Usually, it is based on the current state of the data object, D, and the condition for triggering. Referring to the above example on the program stock trading system, the DataStateD can be defined as the difference between the price of the stock set in the condition for triggering and the current price of the stock. A higher criticality will be assigned to the one which is triggered from a greater difference in stock prices. By the use of DataStateD, it is expected that by promoting the priorities of the more critical triggered transactions to higher levels, they will have higher probabilities to commit even with a small slack time. The side effect is that it may affects the timely installation of updates if their priorities are even higher than the priorities of the updates. The resulting effect will be high probability of aborts due to the access of invalid data objects.

5

Performance Studies

In order to study the performance of the proposed deadline and priority assignment approaches, a simulation model has been developed. Simulation experiments have been performed with the immediate and deferred coupling modes for triggering of transactions. The reason of choosing these two coupling modes is that they represent two extremes for triggering of transactions. In

the performance studies, the TDD approach will be compared with the transaction deadline approach (TD).

5.1 RTADBS Model Figure 1 depicts the simulation model which consists of a transaction generator, an update process, a scheduler, a CPU, a ready queue, a database. Transaction Generator Update Process

Ready Queue

Scheduler

CPU

Database Static

transaction accesses a temporal data object, it may trigger a transaction if some of the conditions for triggering are satisfied. After the triggering, the user transaction will be called triggering transaction. Similar to the user transactions, the triggered transactions also consist of a sequence of database operations. In order to maintain the database consistency, a concurrency control protocol is adopted. The optimistic concurrency control with broadcast commit (OCC-BC) is used as most of the previous studies have shown that OCC-based protocols are better than the locking based protocols for RTDBS [12].

5.2 Simulation Parame ters and Measures Temporal

Figure 1. The RTADBS Model The database consists of two types of data objects: temporal and static data objects. Static data objects store static information of the objects in the external environment. Their values do not change frequently with time. The validity of a temporal data object is defined by an absolute validity interval, avi. In order to simplify the model, it is assumed that all the temporal data objects are having the same avi. Since main memory database system can better support real-time applications [1], it is assumed that the database is residing in the main memory. The update process generates updates periodically. Updates are single operation transactions. They capture the current status of the objects in the external environment and refresh the validity of the temporal data objects. Basically, they do not have deadline. Upon creation, a time-stamp is assigned to indicate the time when the value is taken. When the update is installed into the database, this time-stamp will also be recorded in the temporal data object. A temporal data object is valid until the instant when the current time exceeds the time-stamp of the temporal data object by the avi. The transaction generator creates transactions, called user transactions, following the Poisson distribution. A user transaction consists of a sequence of read and write operations. The processing of an operation involves CPU computations and database accesses. It is assumed that each operation will access one data object (either temporal or static data objects) and the required data object of an operation is randomly distributed in the database. The priorities of the updates are assigned to be higher than the priorities of the user transactions and triggered transactions. The transactions and updates queue in the ready queue for the CPU. They are scheduled to use the CPU according to their priorities. It is assumed that the user transactions and triggered transactions are firm real-time. Before the scheduler allocates the CPU to a transaction, it will check its deadline. If it already misses its deadline, it will be aborted immediately. When a user

The simulator is built using CSIM18 [6]. The structure of the simulator follows the model described in the last sub-section. Similar to many previous studies on the study of concurrency control protocols for RTDBS, the end-to-end deadline of a user transaction, Ti , is defined according to the following equation: Deadline = ar(Ti ) + pex(Ti ) × SF where SF is the slack factor, a random variable uniformly chosen from a range. SF denotes how stringent is the deadline relative to the execution time of the transaction. ar(Ti ) is the arrival time of Ti . The predicted execution time of Ti is defined as: pex(Ti ) = T copy × Noper + Nread × Tprocess where Noper is the number of operations in the transaction. Nread is the number of read operations. T copy is the CPU time required to copy the value from or to memory (database) and Tprocess . Is the CPU time required to process the data. In the simulation model, a small database (1000 data objects) is used to create a high data contention environment. The small database also allows us to study the effect of hot-spots, in which a small part of the database is accessed frequently by most of the transactions. The model parameters and their baseline values are follows: System CPU Scheduling : Earliest Deadline First Concurrency Control : OCC-BC Time to Process a Page (T process) : 10 ms Block Copy Time (T copy ) : 0.5 ms

Transaction Arrival Rate of User Transactions (ARur) : 5 – 35 tran/sec Transaction Size (Noper ) : 8 - 24 uniformly distributed Proportion of write operations : 0.25 Triggering Probability : 0.6 Size of Triggered Transaction : 8-24 uniformly distributed Slack Factor (SF) : 2.5-4.5 uniformly distributed

Update Arrival Rate of Update Transactions (ARup) : 800 tran / sec avi : 400 - 1000 ms

Database Number of Data Objects Fraction of Temporal Data Objects

: 1000 : 0.1

For a RTADBS, one of the most important performance metrics is the number of deadline missing.

Thus, the primary performance measurement used is the miss rate (MR) which is defined as the number of deadline missing over the total number of transactions generated. We measure two types of miss rates. MRtrigger is the miss rate of the triggered transactions and MRuser is the miss rate of the user transactions (including triggering transactions). In addition, we also measure the restart rate (RR) and the total CPU utilization. Restart rate (RR) is defined as the number of restarts due to data conflicts over the total number of transaction generated. Thus, it is an indicator of the probability of data conflicts. In each simulation experiment, the simulation length is the completion of 20,000 user transactions.

5.3 Performance Results Triggering of transactions can seriously affect the predictability of the system and increase the probability of deadline missing. The impact of triggering of transactions on the performance of the system can be observed in Figure 2 and Figure 3. The MRs of the triggered transactions and the user transactions are much higher than the case with no triggering of transactions. Consistent with our intuition, the MRs of the triggered and user transactions increase with an increase in system workload. As can be observed in the Figure 2 and Figure 3, the performance of the TDD approach is better than the TD approach especially under the immediate coupling mode. The better performance in the TDD approach can be explained by fact that in the TDD approach the temporal constraints of the data objects have also considered in the assignment of deadlines and priorities to the triggered transactions. If the data deadlines are tighter than the original deadlines of the transactions, the triggered transactions are thus assigned to higher priorities and have higher probability to commit. In the TD approach, the MRs of the user and triggered transactions under the immediate coupling mode are higher than that under the deferred coupling mode as depicted in Figure 2 and Figure 3. This is due to two reasons. Firstly, the system workload is lower under the deferred coupling mode as shown in Figure 4. Since the generations of the triggered transactions are after the completion of the triggering transactions, if the deadline of a triggered transaction has already been missed, the triggered transaction will not be generated. Thus, the amount of workload wasted on aborted triggered transactions will be smaller. Secondly, since the executions of the triggered transactions are earlier under the immediately coupling mode, they will have higher probability of missing the temporal constraints of their accessed temporal data objects. The differences in performance between the immediate and deferred coupling modes are much smaller in the TDD approach than under the TD approach. It is because under the TDD approach the same deadline and priority are assigned to the triggered and triggering transactions.

Triggering of transactions increases the probability of data conflict and thus the restart rate will be higher. As shown in Figure 5, the restart rate increases with an increase in system workload. Surprisingly, although the performance of the TDD approach is better (smaller MRs) than the TD approach, the restart rate with the TDD is higher than that in the TD approach under the deferred coupling mode. This can be explained by the late generations of triggered transactions under the deferred coupling mode. In the TD approach, the triggered transactions have higher probability of missing their deadlines even before their executions under the deferred coupling mode. Thus, the resulting number of transaction restarts due to data conflict is smaller. Figures 6 and 7 show the impact of the avi of the data objects on the performance of the TDD approach and the TD approach. The MR is smaller with an increase in avi due to looser data temporal constraints. The differences in performance under the immediate and deferred coupling modes are getting smaller with increase in avi value as the impact of temporal constraints on the deadlines of the transactions is smaller. Consistent with the results in Figure 2 and Figure 3, the performance of the TDD is consistently better than the TD approach due to better scheduling of the transactions. Under the DSD approach, the priorities of the triggered transactions are higher than the updates. As shown in Figure 8, more triggered transactions can commit before their deadlines due to shorter waiting time for the CPU. Since there are not many triggered transactions in the system, the impact on the scheduling of the updates is not significant. Thus, the problem of accessing invalid data objects of the triggered transactions is not serious.

6

Conclusions

A real-time active database system (RTADBS) has to provide the capabilities for timely trigger of transactions and at the same time to process them in a real-time manner. In this paper, we have proposed new deadline and priority assignment approaches for the scheduling of triggered transactions. Since triggering of transactions introduces a number of unpredictable factors, which can affect the system performance, it becomes more difficult to commit the transactions. In the TDD approach, the temporal constraints of the data objects accessed by a triggered transaction will be included in its deadline so that the probability of missing the data deadlines will be much smaller. The data state dependent (DSD) approach includes the importance of the data state for the assignment of priorities to the triggered transactions so that the triggered transactions will have higher probability to commit. In order to solve the unpredictability due to triggering, we also propose the use the effective deadline for the assignment of the priorities of the transactions. Simulation experiments have been performed to study the impact of different deadline constraints, both

Reference [1] R. Abbott, & H. Garcia-Molina, “Scheduling Realtime Transactions: A Performance Evaluation”, ACM Transactions on Database Systems, Volume 17, Number 3, pp. 513-560, 1992. [2] B. Adelberg, H. Garcia-Molina and B. Kao, “Applying Update Stream in a Soft Real-time Database System , in Proceedings of the 1995 ACM SIGMOD Conference, California, pp. 245-256, 1995. [3] S.F. Andler, J. Hansson, J. Eriksson, J. Mellin, M. Berndtsson, B. Eftring, “DeeDS Towards a Distributed and Active Real-Time Database System , SIGMOD Record, volume. 25, number 1, March 1996, pp..38-40. [4] International Workshop on Active and Real-time Database Systems, Sweden, May 1995. [5] Mikael Berndtsson, Jörgen Hansson, “Workshop Report: The First International Workshop on Active and Real-Time Database Systems , SIGMOD Record, volume 25, number 1, pp. 64-66, March 1996. [6] CSIM 18 User Guide, Mesquite Software, Inc. (URL: http://www.mesquite.com/ 1_intro.html). [7] P.A. Bernstein, V. hadzilacos and N. Goodman, Concurrency Control and Recovery in Database Systems, Addison-Wesley, Reading, Mass., 1987. [8] Azer Bestavros, “Advances in Real-Time Database Systems Research , SIGMOD Record, Vol. 25, No. 1, pp. 3-7, March 1996. [9] A. Buchmann, J. Zimmermann, J.A. Blakeley and D.L. Wells, “Building an Integrated Active OODBMS: Requirements, Architecture, and Design Decisions , In Proceedings of International Conference on Data Engineering, 1995.

[10] International Workshop on Database: Active and Real-time, U.S.A., November 1996. [11] U. Dayal, B. Blaustein, A. Buchmann, U. Chakravarthy, M. Hsu, R. Ledin, D. McCarthy, A. Rosenthal, S. Sarin, M. J. Carey, M. Livny, R. Jauhari, “The HiPAC Project : Combining Active Database and Timing Constraints , SIGMOD RECORD, volume 17, number 1, March 1988. [12] H.R. Haritsa, M.J. Carey and M.Livny, “Data Access Scheduling in Firm Real-Time Database , Real-time Systems, volume 4, number 3, pp. 203-242, 1992. [13] Henry F.Korth, Nandit Soparkar, Abraham Silberschatz, “Trigger Real-Time Database with Consistency Constraints ”, in Proceedings of the 16 VLDB Conference, Brisbane, pp.71-82, 1990 [14] C.L. Liu and J.W. Layland, “Scheduling Algorithms for Multiprogramming in a Hard-RealTime Environment , Journal of ACM, volume 20, number 1, pp. 46-61, 1973. [15] K. Ramamritham, “Real-time Databases ”, International Journal of Distributed and Parallel Databases, volume 1, number 2, pages 199-226, 1993. [16] Krithi Ramamritham, Raju Sivasankaran, John A. Stankovic, Don T. Towsley, Ming Xiong, “Integrating Temporal, Real-Time, and Active Databases , SIGMOD RECORD, Vol. 25, No. 1, p.8 - p.12, 1996. [17] R.M. Sivasankaran, John A. Stankovic, Don Towsley, Bhaskar Purimetla, Krithi Ramamritham, “Priority Assignment in Real-Time Active Database , The VLDB Journal, volume 5, number 1, pp .19 - 34, 1996. [18] P. S. Yu, K. L. Wu, K.J. Lin and S.H. Son, “On Real-time Databases: Concurrency Control and Scheduling , Proceedings of IEEE, volume 82, number 1, pp. 140-157, 1994. Miss Rate of User Transactions avi=400ms, ARup=800 40 35 30 25 MR(%)

transactions and data, on the performance of priority and deadline assignment approaches under the deferred and immediate coupling modes for triggering. Although the triggered transactions are commit dependent on the transactions, which trigger them, we have found that their performance is also greatly affected by the deadline constraints of the temporal data objects and the coupling modes used for their triggering. The TDD approach can improve the system performance especially under the immediate coupling mode. In the TDD approach, the performance of the system under the deferred coupling mode is similar to the immediate coupling mode as the triggered and triggering transactions are having the same priorities. On the contrary, in the TD approach, the performance under the deferred coupling mode is much better than under the immediately coupling mode due to the temporal constraints of the data objects. If the expected execution times of the transactions are predictable, the system performance can further be improved by using the effective deadline approach.

No Triggering 20

TD-Imm

15

TD-Def TDD-Imm

10

TDD-Def 5 0 5

10

15

20

25

30

Arrival Rate of User Transactions (trans/sec)

Figure 2: Impact of Arrival Rate of User Transactions on Miss Rate of User Transactions

35

65 60 55 50 45 40 35 30 25 20 15 10 5 0

Total CPU Utilization avi=400ms, ARup=800 100 90

No Triggering

80

TD-Imm TD-Def

70 CPU(%)

MR(%)

Miss Rate of Triggered Transactions avi=400ms, ARup=800

TDD-Imm

60

TDD-Def

50

TD-Imm TD-Def

40

TDD-Imm

20

TDD-Def

10

30

0

5

10

15

20

25

30

5

35

10

Arrival Rate of User Transactions (trans/sec)

Figure 3: Impact of Arrival Rate of User Transactions on Miss Rate of Triggered Transactions

25

30

35

Miss Rate of User Transactions ARup=800, ARur=10

No Triggering

50

TD-Imm TD-Def TDD-Imm

40

TDD-Def

30

TD-Imm TD-Def TDD-Imm

MR(%)

RR(%)

20

Figure 4: Impact of Arrival Rate of User Transactions on CPU Utilization

Restart Rate avi=400ms, Arup=800 65 60 55 50 45 40 35 30 25 20 15 10 5 0

15

Arrival Rate of User Transactions (trans/sec)

TDD-Def

20

10

0

5

10

15

20

25

30

300

35

400

500

600 avi (ms)

700

800

900

Arrival Rate of User Transactions (trans/sec)

Figure 5: Impact of Arrival Rate of User Transactions on Restart Rate

Figure 6: Impact of avi of Data Objects on Miss Rate of User Transactions

Miss Rate of Triggered Transactions ARup=800, ARur=10

Miss Rate of Triggered Transactions avi=500, ARup=800

50

80 70

40

TD-Imm TD-Def

50

MR(%)

MR (%)

60

TDD-Imm 40 TDD-Def

30

20

30

TDD-Imm TDD-Def

20

DSD-TDD-Imm DSD-TDD-Def

10

10 0 300

0

400

500

600

700

800

avi (ms)

Figure 7: Impact of avi of Data Objects on Miss Rate of Triggered Transactions

900

5

10

15

20

25

30

35

Arrival Rate of User Transactions

Figure 8: Impact of Arrival Rate of User Transactions on Miss rate of Triggered Transactions under DSD