Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 40 Next »

JDBC pools configuration

BTM XA datasources can be created via some java code or via a BTM-specific tool called the Resource Loader. You are free to choose the method you prefer, there is absolutely no difference between them.

Contents

Using the BTM API

BTM comes bundled with a JDBC XA connection pool which is very easy to configure. You basically have to create an instance of bitronix.tm.resource.jdbc.PoolingDataSource set some properties and you're done.

Here is an example of datasource creation that connects to an Oracle database:

1. The Bitronix PoolingDataSource is a javabean that implements java.sql.DataSource.
2. You have to specify the driver's XADataSource implementation here.
3. Each datasource must be assigned a unique name. This is required for distributed crash recovery.
4. This datasource can contain at least 0 connection. 0 is the default value when unspecified.
5. This datasource can contain at most 5 connections.
6. If there aren't enough connections in the pool to fulfill a request, new connections will be created, by increments of 1 at a time.
7. You have to set allowLocalTransactions to true if you want to be able to run SQL statements outside of XA transactions scope. Defaults to false.
8. When specified, this query will be executed to check that the connection is still valid before handing it to the application code.
9. Set useTmJoin to false if the vendor's XADataSource implementation does not implement XAResource.isSameRM() properly. Refer to the JdbcXaSupportEvaluation page to see if your database needs it. Defaults to true.
10. Set deferConnectionRelease to false if the vendor's XADataSource implementation supports transactions interleaving. Refer to the JdbcXaSupportEvaluation page to see if your database supports it. Defaults to true.
11. Set automaticEnlistingEnabled to false if you do not want the PoolingDataSource to automatically enlist/delist the connections into the XA transactions. You then have to enlist XAResource}}s manually into the {{Transaction objects for them to participate in XA transactions. Defaults to true.
12. The amount of seconds the pool will block when a connection is requested but the pool is empty and cannot grow anymore. Defaults to 30.
13. The amount of seconds the pool will wait when a connection has been tested invalid before trying to acquire a new one. Defaults to 1.
14. The amount of prepared statements cached per pooled connection. Defaults to 0, meaning statement caching is disabled.
15,16,17. The driverProperties is a java.util.Properties object. You have to add into it a set of property name / property value of the OracleXADataSource class. You have to refer to the driver's documentation to know what can / has to be set. The OracleXADataSource javadoc contains this list for the Oracle case. BTM will perform conversion from String to boolean or to int when necessary.
18,19. You can now use the PoolingDataSource like any other java.sql.DataSource.
20. Remember to close the PoolingDataSource after you're done with it to release the connections.

No XADataSource implementation ?

Icon

If your database vendor does not provide a XADataSource implementation, you should have a look at the Last Resource Commit optimization.

Minimal settings

You do not have to set properties that have a default value. Here is a simplified version of the previous code creating a PoolingDataSource with minimal settings:

This will create a PoolingDataSource that will work exactly the same as the previous one. The only difference is that unspecified properties have been left untouched with their default value.

Eager initialization

The connection pool will be initialized during the first call to getConnection(). It might be desirable to initialize the pool eagerly, like during application startup rather than having to wait for the first requests. This can be done by calling init():

Now line 10 will initialize the pool instead of line 11.

Initialization must happen before TM startup

Icon

Please remember that connection pools should always be initialized before BTM starts up, ie: before calling TransactionManagerServices.getTransactionManager() as during initialization, the connection pool will register itself to the transaction manager as recoverable resource.

If you do not follow this rule, BTM might not be able to fully recover XA transactions pending finalization because not all resources are available for startup recovery.

To circumvent this problem, BTM will run a full recovery each time a new connection pool is registered after it started up. You should not rely on this as pending XA transactions might still hold locks on registered connection pools that could block new transactions.

If this is problematic for you, please let us know by voting for BTM-4.

Using the Resource Loader

A datasource configuration utility is also bundled with BTM. It is convenient to use it rather than create your datasources in code. Refer to the Resource Loader page for more details.

Here is the equivalent Resource Loader configuration of the previous code example:

Datasource initialization / shutdown

Icon

The Resource Loader will always eager initialize the created datasources and close them when the transaction manager shuts down.

You just have to write those properties in a simple text file and tell BTM where to load it by setting the resourceConfigurationFilename property of the Configuration object.

Now you also have to know how to get the datasource created by the Resource Loader. There are multiple ways:

  • Add bitronix.tm.resource.bind=true to your resource loader properties file. The datasources will then be bound to the default JNDI server using their uniqueName as their JNDI name.
  • Another way (in case the JNDI context is read only, like in Tomcat) is to bind a bitronix.tm.resource.ResourceFactory object, passing it a javax.naming.Reference containing a javax.naming.StringRefAddr containing the datasource's uniqueName as addrType somewhere in your JNDI tree. The bitronix.tm.resource.ResourceFactory class will just return the datasource with the specified uniqueName. This is explained more in-depth in the Tomcat integration page.
  • No labels