时间一致性

实时数据库系统与非实时系统的主要区别在于：传统数据库管理系统注重吞吐量和平均响应时间，保持逻辑（内部）一致性；而实时数据库管理系统不仅需要提供可预测的响应时间和保证关键事务的完成，还必须确保时间（外部）一致性和数据反映当前物理环境。

因此，实时数据库系统设计应避免引入不可预测延迟的技术，以确保满足所有系统事件的截止时间。为了实现事务提交或回滚时间的保证，SmartEDB/rt 数据库运行时依赖以下断言：

实时事务时间线结构

现在让我们来看看实时事务时间轴，并澄清一些术语。

交易截止期限是为完成交易所分配的总时间。

截止期限控制点——图中的红点，表示从交易开始到实时内核必须开始中断并回滚交易以满足其截止期限所经过的时间，前提是应用程序尚未提交交易。
图中的蓝色区域是交易队列时间间隔。它表示交易在数据库内核队列中等待开始执行的时间。队列时间间隔由数据库内核调度程序控制，且绝不会超过交易截止期限。如果等待时间“接近”截止期限，内核将中止交易。
交易回滚时间间隔（图中的橙色区域）表示回滚交易中所做的更改所需的时间，无论该回滚是由内核运行时为强制执行截止期限而发起，还是由应用程序发起。
绿色的交易工作负载时间间隔是交易执行“实际有效工作”的时间段。
工作负载间隔内的点称为截止期限验证检查点。这些检查点是数据库内核代码中的位置，在这些位置会将事务的持续时间与设定的截止时间进行对比。
事务队列代表的是 SmartEDB 运行时内部结构，它会登记所有已请求的事务。

估计控制点位置

某些事务模式能够更精确地确定事务回滚时间的最坏情况。中断的读写事务必须将数据和数据库运行时恢复到事务开始前的状态。在最坏的情况下，事务内的应用程序会更新多个对象。在这种情况下，应用和撤销修改所需的时间间隔相等，如下所示：

    trans_start()
    {
        object1_update();
        object2_update();
        ....
    }
    transaction_end()

然而，在实际操作中，这种情况并不常见。即使是在读写事务的背景下，大多数应用程序也会执行数据库查找和其他只读操作，在数据库运行时之外执行代码或让出给其他操作系统任务。此外，对同一个数据库对象可能会进行多次修改。对一个对象的首次更新是最耗时的，因为会创建该对象的一个副本以防需要回滚。对同一个对象的后续更新并非“免费”，但完成所需的时间更短。回滚时间与应用于该对象的更新次数无关：

    trans_start(); 
    {
        object1_update();
        if (lookup()== FOUND)
        object2_update();
        read_external_sensor();
        object3_update();
        object1_update();
        ....
    }
    transaction_end();

所有这些因素都有助于缩短阈值回滚时间。没有正式的机制来确定最小阈值。实际上，它是通过经验来确定的。