I am using Apache Tomcat JDBC connection pool library in my project and configured the context.xml file accordingly. My application instance needs to run at multiple locations, but load on the application will be different, so I want to modify the maxActive size and some other property based on the customer size at particular instance at runtime.
<Context path="/abc"
docBase="abc"
debug="5"
reloadable="false"
crossContext="true">
<Resource name="jdbc/abc"
auth="Container"
type="javax.sql.DataSource"
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
driverClassName="xxxxx"
url="xxxxxxx"
username="xxxxx" password="xxxxxx"
maxActive="20"
initialSize="0"
...
/>
</Context>
There is nothing special about a datasource created through JNDI: if you know its class (org.apache.tomcat.jdbc.pool.DataSource in your case), you can cast to that class and use the available setters to configure it:
private void customizeDataSource(final DataSource ds) {
if (ds instanceof PoolConfiguration) {
final PoolConfiguration poolConfig = (PoolConfiguration) ds;
poolConfig.setMaxActive(10);
}
}
(see the definition of PoolConfiguration). Implementations of javax.sql.DataSource also implement a very useful interface Wrapper, which may come handy if your code wraps the Tomcat JDBC datasource in something else:
private void customizeDataSource(final DataSource ds) throws SQLException {
if (ds.isWrapperFor(PoolConfiguration.class)) {
final PoolConfiguration poolConfig = ds.unwrap(PoolConfiguration.class);
poolConfig.setMaxActive(10);
}
}
There are however some problems that can arise from the programmatic approach above:
tomcat-jdbc.jar with your application, only JNDI resources configured in your context.xml will be recognized by your code. Those in GlobalNamingResources will use the copy of org.apache.tomcat.jdbc.pool.DataSource bundled with Tomcat and will not match the instanceof condition.tomcat-jdbc.jar into your WAR file, you must make sure that the parameters you set are supported by all versions of Tomcat on which your application will run.MySQL connects rapidly, thereby making connection pooling of limited use.
Usually, if there is a performance problem it is better handled by other techniques -- composite indexes, reformulating queries, working around optimization limitations of MySQL, etc.
Would you care to back up a step and let's analyze the bottlenecks?