An Intelligent Transaction refers to the propagation of changes from a replica database to the master database. The data of all the replica databases is unofficial. Any modifications to the data on a replica database are tentative. The modifications become official only when they are successfully validated and committed in the master database.

The "create now in replica, commit later in master" requirement extends the lifecycle of a transaction from a fraction of a second to an undefined duration. In a multi-database system, transactions are propagated from replica databases to the master database over a period of time that can vary from seconds to even weeks. The challenge of such a transaction is to ensure that whenever it is validated and committed to the master database, it changes the master database from one consistent state to another consistent state.

A database is consistent if the transactions that modify the contents of the database meet the following criteria at the commit moment of the transaction:

When the propagated replica transaction is eventually committed in the master database, it is possible that the state of the master database is different from the state of the replica database (where the transaction was originally created). The state of the master database might have changed because of propagated transactions from other replica databases or updates done directly to the master database after the replica received a refresh. For this reason, the replica transaction cannot be used in the master database with its original content.

To address the consistency requirement in the two-tier replication model, each transaction that can become invalid during its lifecycle must contain built-in business logic for ensuring that the master database remains consistent when the transaction is committed. If the database becomes inconsistent with the original behavior of the transaction, the transaction must detect this and change the behavior so that the consistency of the master database is maintained.

The Intelligent Transaction model provides a framework for implementing transactions with long life spans. Transaction propagation in Advanced Replication architecture is based on solidDB Intelligent Transaction technology. See Propagate and refresh example for a simple illustration of propagating and refreshing data when some records are accepted by the master database and some are not.

To illustrate Intelligent Transaction implementation, assume an order entry application has a business rule that customers must not exceed their credit limit. If the limit has been exceeded, new orders are prohibited.

In a multi-database system it is possible that the customer credit limit in a replica database is OK, whereas the same data in the master database indicates a limit overrun. In this situation, a customer can still enter an order to the replica database, because the information about the limit overrun has not reached that database yet. However, when the "add a new order" transaction is propagated from the replica to the master database, it must not be committed in its original form, because that would mean a violation of the "credit limit" business rule. Instead the transaction needs to change its behavior to be valid. For instance, the "status" column of the order must be given the value "invalid" in the master database to keep the order separate from the valid orders. The invalid order can be refreshed back to the replica to notify the replica users that the transaction has failed.