{scrollbar}

In order for XA transactions to work properly, INLINE

each Geronimo instance connecting to a resource manager such as an XA capable database or jms needs to have a globally unique and permanent Id.

The Id needs to be unique to avoid the same Xid being generated by several geronimo instances, which would indicate to the resource manager that work done in completely unrelated transactions from different servers was actually part of the same transaction, and the Id needs to be permanent so that the recovery process can associate in-doubt transactions with the correct server.

In Geronimo this id is a byte sequence configured in the XidFactory service in the transaction plugin. Do not change this while the server is running or while there are any in-doubt transactions anywhere in your system. This is the server identity as far as the xa system is concerned. For instance if a server becomes permanently unavailable due to hardware failure you can recover in-doubt transactions it is responsible for by setting up another server with the same apps and the dead server's TmId.

How to set the TmId (Geronimo 2.1.2, 2.2, and later)

Edit the line

TmId=71,84,77,73,68

in var/config/config-substitutions.properties to contain a unique byte sequence.

How to set the TmId (Geronimo 2.1.0 and 2.1.1)

Modify the var/config/config.xml file to look more like this (add the XidFactory element):

<module name="org.apache.geronimo.configs/transaction/2.1.1/car"> <gbean name="XidFactory"> <attribute name="tmId">71,84,77,73,68</attribute> </gbean> <gbean name="ResourceBindings"> <attribute name="format">${ResourceBindingsFormat}</attribute> <attribute name="nameInNamespace">${ResourceBindingsNameInNamespace}</attribute> <attribute name="namePattern">${ResourceBindingsNamePattern}</attribute> <attribute name="abstractNameQuery">${ResourceBindingsQuery}</attribute> </gbean> </module>

Again, use a unique byte sequence.

  • No labels

1 Comment

  1. Ralf Baumhof

    A very useful property that can be set here ist the defaultTransactionTimeoutSeconds. The default is approximately 900 seconds. So, if long running batch jobs are executing (in example scheduled by Quartz framework) in container, these jobs are canceld and database changes are rolled back by transaction manager at end of run. This is done even if all work was valid. So, you will never see an error monitoring the database

     <module name="org.apache.geronimo.configs/transaction/2.1.4/car">
    <gbean name="TransactionManager">
       <attribute name="defaultTransactionTimeoutSeconds">3600</attribute>
    </gbean