I'm evaluating Atomikos for use at my company.
I have a simple demo spring application that starts an XA transaction, updates a database, and sends a JMS message. My datasource is non XA, so I'm using AtomikosNonXaDataSource.
I put a breakpoint in the Atomikos source code in CoordinatorStateHandler.commit(boolean, boolean) method after the "coordinator_.setState ( TxState.COMMITTING );" line of code, and kill the application, to simulate a failure after Atomikos has decided to commit the transaction but before informing participants.
When I restart the application, I get repeated warnings in the logs, about 5 per second: "Local heuristic termination of coordinator 188.8.131.52.tm0000200001 with state HEUR_HAZARD"
This makes sense to me: it is trying to commit the transaction on the non xa datasource that has already rolled back, and so this is a heuristic hazard.
My issue is why does Atomikos effectively 'spam' the logs with 5 messages per second, can I slow this down? Also, how I 'resolve' the heuristic hazard condition in a production environment, the only way I've found so far is to delete the transaction logs.
readOnly seems to clear up the warnings - thanks. Actually I've managed to get my database's XA driver (ingres) working in any case.
I had only one non-xa resource: the database. Why do you say I have two? In fact my other XA resource I am enlisting manually (it is the weblogic transaction manager actually - which is needed to use weblogic JMS in a remote transaction manager like Atomikos).
I have another related issue - but I'll start a new topic for this.
This topic is archived. No further replies will be accepted.Other recent topics