Some performance issues in distributed real time database systems.

Distributed real time database systems (DRTDBSs) can be defined as database systems that support real time transactions. They are used for a wide spectrum of applications such as air traffic control, stock market trading, banking, telemedicine etc. In DRTDBS, there are two types of transactions: global and local. The global transactions are distributed real-time transaction executed at more than one site whereas the local transactions are executed at generating site only. A commonly model used for distributed real time transaction consists of a process, called coordinator, which is executed at the site where the transaction is submitted, and a collection of other processes called cohorts executing at various sites where the required data items reside.
Transactions in a real time database are classified into three types, viz. hard, soft and firm. The classification is based on how the application is affected by the violation of transaction time constraints. This thesis reports efficient solutions for some of the issues important to the performance of firm deadline based DRTDBS.
The performance of DRTDBS depends on several factors such as specification of transaction’s deadline, priority assignment policy, scheduling transactions with deadlines, time cognizant buffer and locks management, commit procedure etc. One of the primary performance determinants is the policy used to schedule transactions for the system resources. The resources that are typically scheduled are processors, main memory, disks and the data items stored in database.
In order to resolve the contention for these resources, DRTDBSs have to establish a priority ordering among the cohorts. This ordering should minimize the percentage of missed transactions which is the primary performance metric, defined as percentage of input transactions that the system is unable to complete before their deadlines. We proposed a scheme where the priority of each cohort is determined independently on the basis of the locks required by it at its execution site. This is in contrast to earlier schemes where cohort inherits its real time priority from its parent. In our scheme, each cohort is assigned an initial priority based on the number of locks required by the cohort at its execution site. The cohort uses this priority for central processing unit (CPU) scheduling. However, when there is a data contention between a low priority executing cohort and a high priority newly arrived cohort, temporary intermediate priorities of both are calculated. These intermediate priorities are based on the remaining execution time needed by the lock holding low priority cohort and the slack time available with the newly arrived higher priority cohort. The data contention is resolved on the basis of these priorities. The deadlines of the global and the local transactions are computed based on the formula developed.
DRTDBS implements a transaction commit protocol to ensure transaction atomicity. A commit protocol ensures that all participating sites agree on the final outcome of the transaction (commit or abort). The commit processing can result in a significant increase in transaction execution time due to exchange of multiple messages in multiple phases among the participating sites and maintaining several log records. This may influence the transaction miss percentage. Therefore, the design of commit protocol becomes an important performance issue in the design of DRTDBS. The existing commit protocols try to improve system performance by permitting a lock holding transaction (lender) to lend its data to other transactions (borrower). This creates dependencies between lender and borrower. We first redefine the dependencies created due to read/update type locks, and then propose a static two phase locking with higher priority based, write-update type, ideal for fast and timeliness commit protocol (named as SWIFT). We observe that, when communication delay is large, most of the transactions are aborted during their commit or locking phase; and not during their execution phase, particularly when database is main memory resident. Based on this observation, a cohort sends a WORKSTARTED message in SWIFT before the start of its execution in contrast to earlier protocol where cohort sends WORKDONE message after the completion of its execution. Our protocol also allows a dependent cohort to send WORKSTARTED message if the dependency is only commit dependency. The simulation results show