Presumed abort mode is activated when a failure occurs before a
distributed transaction starts to commit.
If you have a distributed transaction that spans several servers, transactional
locks may be held by resource managers involved in that work. When a failure
occurs before that distributed transaction has started to commit, the product
and the resource managers go into presumed abort mode. In this
mode, the resource managers rolls back the transaction.
- The effect of a server failure or communications failure will vary depending
on which server is running the work at the time of failure.
- An OTS timeout may be required to rollback the subordinate branches of
the distributed transaction tree.
Example: A common case of this is when you have a server B web client
that is driving a session bean in the same server. That session bean has executed
work against entity beans in servers C and D. All of the servers are involved
in the same distributed, global transaction. Suddenly, server B fails while
the session bean is InFlight (meaning it hadn't started to commit yet). Servers
C and D are waiting for more work or the start of the two-phase commit protocol,
but, while in this state, the transactional locks may still be held by the
resource managers. So, the server roles are as follows:
- Server A: Servlet/JavaServer Page executed
- Server B: Session bean accessed
- Server C: Entity bean accessed
- Server D: Entity bean accessed
After the timeout occurs, because the session bean is InFlight at the
time of the failure, the product rolls back the transaction branch.
When local resource managers are involved, RRS ensures that they are called
to perform presumed abort processing. When doing recovery, RRS works with
the resource managers to ensure that the recovery is done properly. When a
failure occurs while work is InFlight, RRS directs the resource managers involved
in the local UR to rollback.
The product always assumes that there is recovery to do. Every time a server
comes up, it does something different depending in which mode it is running:
- If the server is running in restart/recovery mode, the product checks
to see whether there is any recovery required. If recovery is required, the
product attempts to complete the recovery and either succeeds or terminates.
- If the server is running normally, the restart/recovery transaction does
not have to complete before the server takes on new work. After the server
determines what the restart work is, it begins to take in new work items.
Processing of the restart/recovery transaction continues along with the processing
of new work items.