Resolving in-doubt transactions

The Recovery Manager automatically attempts to recover XA transactions that are in-doubt. The Recovery Manager automatically recovers a transaction if all branches in the transaction can be either rolled back or committed without being in an inconsistent state.

An XA transaction is in doubt when a branch in the transaction fails to commit. For example, an XA transaction can become in doubt if the database that the NexJ application is attempting to commit to becomes unavailable. A transaction is inconsistent if it contains branches that are both committed and rolled back. A transaction is consistent if it contains branches that have been committed or not attempted yet, or branches that have been rolled back or not attempted yet.

If an in-doubt transaction cannot be automatically resolved, you must manually resolve the transaction branches in the external resource, then mark them as committed or rolled back in NexJ System Admin Console. Then, the Recovery Manager will attempt to recover those transactions again.

For example, assume that a transaction has five branches. The first two branches commit successfully and the third is rolled back heuristically. The fourth and fifth branches are not attempted. After logging into the external resource and manually committing the third branch, you mark the third branch as committed in NexJ System Admin Console. Then, the Recovery Manager attempts to commit the fourth and fifth branches.

Alternatively, you could roll back branches one and two and mark them as rolled back in NexJ System Admin Console. Then, the Recovery Manager would attempt to roll back the fourth and fifth branches.