Transaction Recovery Configuration

XA enabled shared resources (SRs) participate in global transactions. Global transactions are transactions that are coordinated by the transaction manager (TM) within a node. In the event of a crash of the node, the shared resources can update themselves to the decided state of the global transaction when they recover.

Nodes bundle the Geronimo transaction manager which is configured to use a HOWL's transaction logger to record the state of transactions, that is, the names of the XA SRs involved in each transaction, whether they are prepared/committed, and also the overall decision to commit/rollback the transaction.

The Geronimo TM requires a persistent TM ID (unchanged over restarts) in order to be able to identify the transactions it initiated in the HOWL logs. If this ID is lost, the TM will not be able to correctly resolve the undecided transactions of recovering XA resources. Since it has this persistent TM ID, there also needs to be a persistent transaction count, in order to have consistently unique transaction IDs (made by coupling the two). The ID and the count are stored in the folder CONFIG_HOME/tibcohost/hostName/nodes/nodename/work/GeronimoTMID in the files tmid.bin and xidcount.txt.

Outbound XA SRs (for example, JDBC-XA, JMS) are recovered when a node is restarted and the SRs are initialized. Recovery code will automatically create a connection to the actual resource and recover it. Inbound XA SRs are recovered when the node restarts when the application initializes the transport endpoints with the resource adapter. Recovery code will automatically create a connection to the actual resource and recover it.

Transaction recovery will not work under the following circumstances:

• HOWL logs are deleted
• The TM ID file is deleted
• (Outbound SRs) If, when a node restarts, the SR has been undeployed/removed.
• (Outbound SRs) The SR has been deployed without authentication credentials (that is, the authentication credentials are to be supplied at runtime). Recovery code will not be able to create a connection because it won't have the credentials.
• Recovery does not work without a restart. For example, if the transaction manager loses connection with an XA SR at some point during transaction commitment, the transaction branch of the XA SR may remain in prepared state and not be recovered until the TIBCO Host instance is restarted.

For information on configuring the log files, see Configuration Properties for HOWL Log Files.

17 Nov 2009 17:48:06,312 [TxRecoveryThread: java:V13_NewJDBCResource1] [ERROR] RecoveryController - Recovery error
javax.transaction.xa.XAException
 at oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:703)
 at com.tibco.amf.sharedresource.runtime.tibcohost.jdbcxa.WrappedXAResource.recover (WrappedXAResource.java:122)
 at org.apache.geronimo.transaction.manager.WrapperNamedXAResource.recover (WrapperNamedXAResource.java:74)
 at org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceManager (RecoveryImpl.java:98)
 at org.apache.geronimo.transaction.manager.TransactionManagerImpl.recoverResourceManager
  (TransactionManagerImpl.java:352)
 at org.apache.geronimo.connector.outbound.AbstractConnectionManager.doRecovery
  (AbstractConnectionManager.java:70)
 at com.tibco.amf.resources.tibcohost.geronimo.transaction.ResourceRecoverer.recoverUsingMCF
  (ResourceRecoverer.java:112)
 at com.tibco.amf.resources.tibcohost.geronimo.transaction.ResourceRecoverer.run
  (ResourceRecoverer.java:98)
 at java.lang.Thread.run(Thread.java:662)

GRANT SELECT ON sys.dba_pending_transactions TO user
GRANT EXECUTE ON sys.dbms_xa TO user
GRANT SELECT ON sys.dba_2pc_pending TO user