Configuring high concurrency DataSource in VMware vFabric tc Server 2.0 to 2.6 (2005475)
This article provides information on configuring the VMware vFabric tc Server's High Concurrency DataSource to recover from connectivity issues without having to restart the server.
In a production environment, it is recommended that you configure the vFabric tc Server's High Concurrency DataSource so it can recover from connection problems without requiring the server to be restarted.
To configure a robust DataSource that is capable of recovering from connection problems, use these properties:
The list above can be divided into three properties sub-groups:
- validationQuery, testOnBorrow, and validationInterval
- validationQuery, testWhileIdle, timeBetweenEvictionRunsMillis
- removeAbandoned, removeAbandonedTimeout, logAbandoned
The properties in Group 1, when used together, can provide connection recovery. For example, you may use this recovery if a database is routinely shut down for back-ups or maintenance. When the database is shutdown, all connections in the application's pool are invalidated. If the DataSource is configured with the validationQuery, testOnBorrow, and validationInterval properties, the High Concurrency DataSource is able to detect bad connections, remove them from the pool, and replace them with new connections.
For example, validationQuery is set to SELECT 1 FROM DUAL, testOnBorrow is set to true and validationInterval is set to 30 seconds, the High Concurrency DataSource will execute the validationQuery on each connection before the connection is given to your application. If the query executes as expected, the connection is valid; if the query fails, the connection is invalid. To prevent extraneous queries, once validationQuery is successfully executed on a connection, it does not execute for an other 30 seconds (i.e. it is trusted as good until validationInterval expires).
The properties in Group 2, when used together, provide an alternative method of achieving the same connection recovery as described in the first option. While these properties achieve roughly the same goal, they do so in a different manner. With these properties, connections are again validated, but the validation does not occur as the connections are taken from the pool. Instead, the pool creates a thread which periodically executes the validation query on idle connections in the pool. If it encounters a connection where the validation query fails , the connection is removed from the pool.
For example, validationQuery is set to SELECT 1 FROM DUAL, testWhileIdle is set to true and timeBetweenEvictionRunMillis is set to 5 seconds, the High Concurrency DataSource creates a new thread. This new thread loops, executing the validationQuery on each idle connection and pausing after each iteration to wait for timeBetweenEvictionRunMillis msecs.
Options 1 & 2
The first set of properties can be used to implement test on demand validation, whereas the second set of properties can be used to implement continuous validation. It is also possible to use both sets of properties, so you can have continuous and test on demand validation. The exact configuration that you adopt depends on the requirements of your application.
The third set of properties is a bit different than the first two sets. This set of properties can be used to recover connections that are not properly closed by the application. If a connection is not closed properly, it is never correctly returned to the pool. Eventually, if enough connections are not properly returned to the pool, the pool will be exhausted.
To prevent this from happening, you can configure removeAbandoned, removeAbandonedTimeout and logAbandoned. In a production environment, the following settings are recommended. Set removeAbandoned to false, logAbandoned to true and removeAbandonedTimeout to 60 seconds (or longer if you have longer running queries in your application). This configuration allows the pool to check and detect connection that may have been abandoned. When an abandoned connection is detected, it is logged so that an application developer can then investigate if there is a problem in the code.
To configure a robust High Concurrency DataSource for a production system, you must use either Option 1 or Option 2.
Note: Most of the time, it is considered overkill to configure both Option 1 and Option 2. However, your requirements may state that your application can use both Option 1 and Option 2 together.
For any application that manually handles connections (such as legacy code, JDBC code), it is highly recommended that you add Option 3 to the configuration. The addition of Option 3 would be in conjunction with the recommended Option 1 and Option 2.