Explicit versus Implicit Transactions

All operations that modify a data object are associated with a transaction. However, the user is not required to use transactions and can issue a command that modifies a data object without using a transaction. In this case, the TIBCO Patterns server creates an implicit transaction that exists for the life of the command, and is automatically committed or aborted when the command completes. The user is unaware of this and commands behave as expected.

The user can create an explicit transaction and associate commands with this transaction. In this case, the changes are not committed or aborted when the command completes. Even if the command terminates with an error, the completed changes are not rolled back. However, any partial updates are rolled back to a point that ensures that the objects involved are in a usable state. For example, if a command is issued to add a large set of records, and the do max work flag is not set, normally an error on one record causes all records added to be rolled back. However, under an explicit transaction, the records that were added are left in the table, only any partial updates of the record that had the error are rolled back. So when associated with an explicit transaction, a command always leaves all objects in a usable state, but the rolling back or committing of any completed operations is not done until the transaction is committed or aborted.

After creating an explicit transaction and performing all of the desired operations for that transaction, the user should either commit or abort the transaction. However, if any of the commands associated with the transaction failed, an attempt to commit the transaction is rejected. The user can override this restriction and forcibly commit the transaction, but it is strongly discouraged. The state of the data after an error is indeterminate. Although the data might be usable from the standpoint that it does not crash the TIBCO Patterns server, it is probably not valid from the user's point of view. The user should always abort transactions where commands failed with an error.

Note: For transactions a command is considered to have failed if, on executing in an implicit transaction instead of an explicit transaction, it rolls back all the changes. Some commands might return an error code but still commit their changes. An example is, a partial checkpoint or partial restore error code from a checkpoint or restore command. For the purposes of transaction processing, these commands are considered to have succeeded even though they returned an error message.