Recently, after upgrading my J2EE project I had to spend some time on two unexpected (right! "nobody expects unexpected exceptions") issues that stopped the development for a while. The first one occurred while JBoss launch - server log errored me about a wrong EAR structure. After I had sorted this issue out (that occurs the Maven fault), log shouted, at run time, about HeuristicMixedException. It sounded like that was a judgement day.
EAR packaging by Maven issue
A wrong EAR structure occurred to be a result of Maven generation of application.xml. My environment was JBoss 5.0.1 GA and eclipse based SpringSource Tool Suite 2.5.0 which embedded m2eclipse plugin (maven v. 3.0).
In generated application.xml EJBs ".jar" extensions was replaced with ".ejb" and hard-coded "lib/" prefix.
What was the solution? Replacing embedded maven 3.0 with external maven 2.2.1 and deleting previous generated application.xml fixed the issue.
javax.transaction.HeuristicMixedException
And here is a second issue that I spent some time on:
org.springframework.transaction.HeuristicCompletionException: Heuristic completion: outcome state is mixed; nested exception is javax.transaction.HeuristicMixedExceptionat org.springframework.transaction.jta.JtaTransactionManager.doCommit...
Heuristic exceptions are thrown by a transaction manager when one of the resources in the transaction decides to commit or roll back the transaction irrespectively to transaction manager. It occurs when transaction consistency may be violated.
As states in jboss.org docs, javax.transaction.HeuristicMixedException is the worst heuristic exception of three (javax.transaction.HeuristicCommitException and javax.transaction.HeuristicRollbackException). It is thrown when some updates are committed and others rolled back.
It looked like a database connections worked fine but some of db operations were pulled back by db engine itself.
Finally, I have found out the solution: After upgrading a database engine (in my case to posgresql 9.0) one of variables should be set in posgresql.conf:
If application uses a prepared transaction then max_prepared_transactions (default is 0) should be set to value not less than max_connections (so that every session can have a prepared transaction pending).