EAServer provides the isRollbackOnly transaction primitive to determine if a transaction is doomed or still viable. If you have a component that does a lot of database updates, it is a good idea to call isRollbackOnly before issuing the updates since they would wind up being rolled back anyway in a doomed transaction.

To illustrate the benefits of using isRollbackOnly, we will use an example where ComponentA inserts a single row into a database, and then ComponentB inserts another 100 rows into the database. Lets look at two different scenarios for using these components.

Scenario 1 - isRollbackOnly is not used
ComponentA inserts 1 row, then calls rollbackWork() to indicate that the transaction should be doomed.
ComponentB inserts 100 rows then calls completeWork() to indicate success

After SessionBean completes, EAServer detects that the transaction is doomed. As a result, the inserts for all 101 rows will be rolled back.

Scenario 2 - isRollbackOnly is used to improve performance
ComponentA inserts 1 row, then calls rollbackWork() to indicate that the transaction should be doomed
ComponentB calls isRollbackOnly() to see if the transaction is still viable before doing any inserts.

After SessionBean completes, EAServer detects that the transaction is doomed. However, in this scenario, one a single insert will be rolled back.

For more information
For more information on the isRollbackOnly transaction primitive, see the EAServer Programmer Guid