Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 5 Introduction to Transactional Business Process Automation : Transaction Failures and Rollbacks

Transaction Failures and Rollbacks
In the transaction example in Figure 1 on page 79, all the external data updates and iProcess case data updates are saved to memory until the case has been processed at which time all the updates are written to the database. This is known as the Commit process.
However, if one or more steps in the transaction are not possible (such as the database is not available), none of the updates are committed and the data is left in the same state as when the transaction started. This is known as the rollback process. Similarly, if the connection to the database is broken, any outstanding transactions are rolled back.
If the instruction is received by the Background but one of the steps it processes subsequently fails (such as a COM+ EAI step calling an application that is not running), then the resource manager returns an error to the Mbox daemon. The Mbox daemon aborts the transaction while the resource manager ensures that all of the steps involved in the transaction are rolled back to their initial state.
Poison Transactions
If a transaction is continually failing and being retried, this can have a serious impact on system performance. It is possible to restrict the number of times a transaction will be retried and to be notified of this failed transaction.
The iProcess installation process sets the message queues to have:
See “Administering Process Attributes” in the TIBCO iProcess Engine: Administrator's Guide for more information about setting process attributes.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved