i made some tests and this is what i found out. Please correct me if i am wrong.
ServiceJBoss = Jboss with MDBs
JMS = JBoss with JBM.
Transaction is coordinated by Transaction Manager on the ServiceJBoss. When ServiceJBoss's crash occurs transaction is interrupted, but xa resources dont know it.
The messages on the JMS server are not gone. They are still in database, but they are propably in some kind of precommit state and hence are not listed and available.
So lets assume that my ServiceJBoss does not have a transaction recovery or it went totally broken.
Will the messages from global transactions initiated by JBossService(which is gone) wait forever for global transaction commit/rollback?
Can I somehow set the JMS to automatically rollback messages from global tx after some time?
I appreciate any help on this subject.
This sounds like a question about how the JBM resource adapter works so I moved it to the HQ forum. Hopefully someone here can help you.
1 of 1 people found this helpful
So the question here really isn't related to HornetQ. The question is how JBoss Messaging, acting as a JTA resource manager, behaves when a transaction manager prepares a transaction involving one of its resources. Specifically, if JBoss Messaging will ever terminate the in-doubt transaction on its own (e.g. via a time-out).
To my knowledge, the answer to that question is, "no." The messages added to or removed from the destination will simply stay in the prepared stage. The in-doubt transaction will not be rolled-back or committed automatically by the resource manager (i.e. JBoss Messaging). Ideally you would have recovery configured in the AS instance which was managing the transaction so all this would be resolved without manual intervention. However, if that isn't configured correctly then the jboss.messaging:service=ServerPeer MBean has several operations you can use to resolve the transaction as far as JBoss Messaging is concerned from the JMX Console:
There is no way to configure JBoss Messaging to terminate the transaction itself.
Note: Even if you resolve the transaction in the resource manager, the transaction manager will still have the in-doubt transaction in its log and it will still complain periodically that it can't recover it.