WAS v8.5 > Reference > Developer detailed usage information

Liberty profile: How database transactions are recovered

Support for transactions is provided by the transaction service. Recovery can occur either when the transaction service is first used, or at server startup. When recovering any in-doubt database transactions, the Liberty profile transaction manager uses either the unique identifier or the JNDI name to locate the current dataSource element.

By default, transaction recovery after a server failure happens when the transaction service is first used (at first lookup of a UserTransaction), rather than at server startup. This behavior can be altered using a pair of configuration attributes for the transaction service. These attributes control when recovery happens, and whether the system waits for recovery to finish before allowing transactional work to proceed. You set these attributes in server.xml. For example, the following settings specify that recovery should occur at server startup, and the server should wait for recovery to finish before allowing transactional work to proceed: 

  <transaction
    recoverOnStartup="true"
    waitForRecovery="true"
  />

You configure a data source by specifying the attributes of the dataSource element in the server.xml configuration file. You also assign a unique identifier or a jndiName attribute for the data source as follows:

You must not change the value of the id or jndiName attribute when a recovery is pending for a transaction in which the data source participated. If we make changes to any other attributes of the dataSource element, those changes are honored for the recovery. This enables you to, for example, add a recoveryAuthDataRef attribute that specifies a database user ID and password to use for recovery.

The database user ID and password to use for recovery are determined according to the following precedence:

  1. If the dataSource element has the recoveryAuthDataRef attribute defined, then the user ID and password from the authData element are used. For example: 
    <authData id="recoveryAuth" user="dbuser1" password="{xor}Oz0vKDtu"/> <dataSource id="ds1" jndiName="jdbc/ds1" jdbcDriverRef="DB2" 
            recoveryAuthDataRef="recoveryAuth" .../>
  2. Otherwise, if container managed authentication is used, then the user ID and password from the container managed authentication alias are used. For example:

    • In the ibm-web-bnd.xml file, we have the following code:

        <resource-ref name="jdbc/ds1ref" binding-name="jdbc/ds1"> <authentication-alias name="user1Auth"/> </resource-ref>
    • In server.xml, we have to define the following code:

  3. Otherwise, the user ID and password from the dataSource element are used. For example:

  4. If none of the above are specified, and the recovery is attempted without any user ID and password, then the behavior is determined by the JDBC driver and database.

If the transaction recovery is performed by an application-defined data source, such as an @DataSourceDefinition annotation or a <data-source> element in the deployment descriptor, we have to make sure the application is running for the data source when the recovery is happening. Configurations in server.xml cannot be used to recover application-defined data sources.


Parent topic: Configuring database connectivity in the Liberty profile


Related

Configure authentication aliases for the Liberty profile


Reference topic |