This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
I am trying to migrate from JBoss 3.2.0 to 5.1.0GA. The application running on the server is invoking remotely EJBs deployed on yet another jboss 3.2.0. When I start JBoss 5.1.0.GA, I can see the following logs:
javax.transaction.HeuristicMixedException javax.transaction.HeuristicMixedException at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commit(TransactionImple.java:254)
at sun.reflect.GeneratedMethodAccessor356.invoke(Unknown Source)
13:42:41,888 WARN [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recoverin
g non-serializable XAResource < 131075, 26, 24, 49459748495454985158101574958529851985651100485850575797484954549851581015749585298519856511004858509750 >
Any clues will be appreciated. Thanks!
SCJP 1.4 - 88%
SCBCD 5.0 - 90%
SCEA - 81%
Joined: Mar 19, 2004
It seems that the implementation of the jboss transaction library (called Arjuna) has been changed between jboss 3.2.0 and 5.1.0.GA:
- in Arjuna 4.2.3.SP5 (used by JBoss 3.2.0), when distributed resource reports heuristic commit, the transaction is not rolled back.
- in Arjuna 4.6.1.GA (used by JBoss 5.1.0.GA), when distributed resource reports heuristic commit, the HEURISTIC_HAZARD is being reported, which causes transaction rollback
The actual change is within the com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelPrepare() method, catch(XAException) block:
old implementation (from line 283):
new implementation (from line 289):
Having said that, I don't understand why this change has been implemented and what is the workaround for the issue?
I have posted this in jboss forum as well, but got frustrated by their web server response time. I'm guessing there is a New Year overload at the mo...
Anyway, I am posting the solution here in case anybody else comes across this issue:
The problem was with our custom XAResource. It reports a heuristic commit in a prepare() method. There two ways to do that from XAResource: either or . Both of them are acceptable by the older version of Arjuna and only the latter one does not cause transaction rollback in the newer Arjuna implementation.
Usually with heuristic decisions you will need to take manual intervention to resolve the decision. Your database vendor should provide tooling to view and resolve them. Log files will provide additional info.
The ArjunaCore recovery manager will keep a record associated with the problem. To removed expired entries follow these instructions.
thanks for the response - the information you posted is very useful. However, as I mentioned above, the root cause was our own custom implementation of XAResource, which was not compatibile with the newer version of Arjuna.