In a traditional client/server system that uses a central database, the validation logic of each transaction is typically in the client application or in the application server services. For instance, in an order entry application, the application logic must check prior to committing the transaction that the credit limit of a customer is not exceeded by the new order.

When propagating a transaction to the master database, similar validation is needed to ensure the database integrity. The only difference is that the transaction validation logic of the application is not available to the synchronization mechanism. Therefore the logic must be bundled into the transaction itself. The following type of validation logic is required in each transaction:

The transactions of a centralized system are very different from the transactions of a multi-database system. In a centralized system, the lifetime of a transaction is typically a fraction of a second and with the DBMS locking mechanism, update conflicts are not possible.

The following diagram illustrates a typical transaction. Within the transaction, some queries are made prior to write operations to validate the contents of the transaction. For example, an order entry system can check that a customer credit limit is OK prior to creating a new order to the customer. During the transaction, the concurrency control mechanism of the server takes care of the update conflicts and other issues caused by concurrent usage of the data.

In a multi-database system, a transaction is initially created and saved in the replica database but finally committed in the master database later when the transaction is propagated there as part of the database synchronization process. The tentatively committed transaction can exist in the system for an unlimited period of time. In other words, the lifecycle of the transaction is entirely different.

In a multi-database system, a transaction has "two lives". The transaction is created as a tentative transaction in the replica database, where it is validated and committed by the business application. The transaction is saved (added to the transaction queue) in the replica database for later propagation to the master database. The transaction has its "second life" when it is propagated to the master database. In the master database, the same validation routines must be performed, that is, the queries that were executed in the replica database. For instance, if a customer credit limit was checked in the replica database to ensure the transaction validity, the same operation must usually be done also in the master database prior to committing the transaction. Otherwise the validity of the transaction cannot be guaranteed in the master database.

To support the extended lifecycle of the two-tier data redundancy model, solidDB Intelligent Transaction allows a transaction to validate itself in the master database and adjust its behavior to ensure the validity of the transaction.