Transactions

The Rules Engine behaviour is transaction-based.

A transaction consists of a series of data manipulations within a user session. Each session only has one current transaction at a time. A transaction is closed by a commit or a rollback command. This is automatically the start of the next transaction.

Transactions allow a client to rollback all the data manipulations performed since the most recent commit. This is useful because it lets the client query and view the result of all the actions in the open transaction and then, on the basis of that view, decide whether these actions must really be committed or, rather, must be undone.

Transactions also allow the RDBMS to guarantee to the client that related data, such as an order record and all the corresponding orderlines, are either ALL processed or NOT AT ALL.

More technically, transactions are also essential for RDBMSs to handle requests of concurrent users correctly.

Transactions contain manipulations. An example of a manipulation is the result of the statement UPDATE ... SET ... WHERE.... Such a statement updates zero, one or many records. Each of these record updates (referred to as row events) can cause one or more new manipulations, like a corrective update rule that updates all children of a parent record.

The typical behaviour of the Rules Engine's corrective action is that, in response to client requests, it transforms or adds to the data manipulations requested by the client (or both), but it does not change transaction boundaries. In other words, the Rules Engine builds on the RDBMS's transaction-based capability. To cover exceptional requirements, the USoft Rules Engine has the capability of executing rule-based behavior in the next transaction based on the commit of the preceding transaction, but this is not a typical implementation.