Temporal Consistency

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.

Real-time transaction timeline structure

Let's look at the real-time transaction timeline now and clarify some terms.

 

Estimating control point position

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.