Heuristic exceptions signal undesired and possibly inconsistent outcomes of the two-phase commit protocol. Even with a transaction manager and full crash recovery, heuristics are possible due to timeouts in various subsystems or resources. Theoretical research has shown that in any system that requires some form of distributed agreement, situations can arise some parts of the system diverge in terms of the global outcome.
There are a number of categories in heuristic outcomes/exceptions:
- HEURISTIC HAZARD This means that part of the transaction may be inconsistent at some later time. This typically happens if a database goes offline whilst processing transactions - and stays offline too long for recovery to succeed. This also happens if you shutdown the transaction core, remove some datasources from your configuration and then restart. In general this can be fixed by adding the required resources to the transaction core, and making sure those resources are up.
- HEURISTIC COMMIT This means that the transaction manager decided to rollback, but somehow all resources already committed on their own - presumably because the transaction manager took too long to inform the resources about its decision to rollback. You don't really have to do anything here because a consistent termination was reached.
- HEURISTIC ROLLBACK Similar to heuristic commit, but the resources have all done a rollback because the commit decision from the transaction manager came too late. You don't really have to do anything here because a consistent termination was reached.
- HEURISTIC MIXED This is probably the worst case: here effectively some parts of the transaction were rolled back and other parts committed. The Xid information in the logs and the JMX controls should point you to internal resource details for manual fixing by a DBA.