By jagadish on Feb 28, 2011
Transparent jdbc-connection-pool re-configuration
|A feature using which
redeployment of jdbc-connection-pool due to attribute or property
change can be handled transparent to applications that use the pool.
Whenever a set of properties / attributes (eg: host-name, port-number
etc.,) of jdbc-connection-pool are changed, the connection-pool is
destroyed and re-created based on the new values. Any application that
is using the connection-pool need to be re-deployed (or application
disable and enable must happen) due to pool re-configuration. Using
this feature, existing applications can roll-over to new connection
pool transparently. It is also possible that there can be in-flight
transactions that is using the connections when the pool is
re-configured. This feature will make sure that the new requests are
queued till re-configuration is complete, however will allow requests
that have already acquired atleast one connection from the pool and is
part of a transaction. Thus, in-flight transactions' connection
requests will be honoured and the transaction can complete.
A new property named 'dynamic-reconfiguration-wait-timeout-in-seconds' will help to allow in-flight requests to complete.
All in-use connections, in-flight transactions that span even after 'wait-timeout' is elapsed will have to be re-tried.Applications can define "application" scoped and "module" scoped resources in the archive.
NOTE : Not all attribute changes to jdbc-connection-pool requires application redeploy, eg., steady-pool-size, max-pool-size etc.,