One of the most important differences between the database systems used by real-time and non-real-time systems is that while a conventional (non-real-time) DBMS aims to achieve good throughput or average response time and maintains logical ("internal") consistency, a real-time DBMS must maintain temporal (“external”) consistency as well as providing predictable response time and guaranteeing the completion of time-critical transactions and making sure that data used by them reflects the current physical environment.
Therefore, the design of a real-time database system should avoid using techniques that introduce unpredictable latencies. The ability to meet all deadlines requested by all system events is vital to real-time systems.
In order to achieve its goal of guaranteed transaction commit or rollback times, the eXtremeDB/rt database runtime relies upon the following assertion:
The time required to reverse any modifications to the database made by a transaction up to any point in the transaction does not exceed the time required to apply those modifications.
Let's look at the real-time transaction timeline now and clarify some terms.
The transaction deadline is the total time allotted for the transaction to complete.
The Deadline control point — the red dot on the diagram, is the time elapsed from the start of the transaction at which, if the application has not yet committed the transaction, the real-time kernel must start to interrupt and rollback the transaction to meet its deadline.
The blue area on the diagram is the Transaction queue time interval. It indicates the time that the transaction waits to start executing in the database kernel's queue. The queue time interval is controlled by the database kernel scheduler and can never be greater than the transaction deadline. If the wait time is “just below” the deadline, the transaction is aborted by the kernel
The Transaction rollback time interval (the orange area on the diagram) indicates the time to reverse changes made in the transaction, whether initiated by the kernel run-time to enforce the deadline, or initiated by the application.
The green Transaction workload time interval is where the transaction does the "real payload work”.
The dots inside the workload interval are called deadline verification checkpoints. These checkpoints are places in the database kernel's code at which the transaction’s elapsed time is checked against the set deadline.
The Transaction queue represents the eXtremeDB runtime internal structure that registers all transactions that have been requested.
Some transaction patterns allow for ascertaining the worst-case scenario of the transaction rollback time with greater precision. An interrupted RW transaction must return the data and the database runtime to the state that existed prior to the start of the transaction. In the worst-case scenario, an application inside a transaction updates multiple objects. In that case, the time intervals required to apply and to reverse the modifications are equal as seen below:
trans_start() { object1_update(); object2_update(); .... } transaction_end()
However, in practice, this is not a prevalent pattern. Even in the context of RW transactions, most applications perform database lookups, and other read-only operations, execute code outside the database runtime or yield to other OS tasks. Moreover, multiple modifications can be made to the same database object. The first update of an object is the most time-consuming because a copy of the object is created in case rollback is needed. Subsequent updates to the same object are not “free”, but take less time to complete. The rollback time is independent of the number of updates applied to the object:
trans_start(); { object1_update(); if (lookup()== FOUND) object2_update(); read_external_sensor(); object3_update(); object1_update(); .... } transaction_end();
All these factors help reduce the threshold rollback time. There is no formalized mechanism to determine the minimum threshold. In practice, it is determined empirically.