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. For customers: the monitoring portal should point you to internal resource details for more information.
- 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. For customers: the monitoring portal should point you to internal resource details for more information.