Hi,
To answer your questions:
1 - Heuristics happen by a resource that is in-doubt and times out fatally. This should not happen often but it really depends on how available your subsystems are.
2 - Heuristic decisions are anomalies in the all-or-nothing (atomic) outcome of a transaction. There is no easy way to recover except for the HAZARD case - where it suffices to retry the commit/rollback until it succeeds. Other cases invariable require administrative intervention at the DBMS or the global application level. Some transaction managers like Atomikos (
http://www.atomikos.com) allow the inclusion of application-specific log comments to aid in recovery of heuristics.
Note that heuristics are possible in ANY distributed system, even those that claim not to use "distributed transactions" for exactly that reason. This is a result of an impossibility theorem proved by Nancy Lynch et al.
To give you a simple example: many people use message queuing instead. In message queuing, heuristics occur in the form of messages moved to some "dead letter queue" because they fail to be delivered in time. With transaction managers like Atomikos, at least you have access to the global context when this happens. Without transactions, there is nothing to fall back to in order to aid in the resolution.
3 - For RM B, at least Atomikos would retry commit until it succeeds. This is a typical heuristic hazard case.
4 - Don't use EJB :-)
Again, heuristics are worst case scenarios. They can happen in all distributed data systems, but in transaction systems at least they are made explicit, managed, avoided if possible, and documented with the global transaction context if all else fails. In other (so-called non-two-phase-commit systems) they are simply ignored in the hope nothing bad will happen.
Best
Guy
Disclaimer: I work for Atomikos.
