Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 1.3, 1.3.1, 1.3.2
-
Fix Version/s: 2.0.0
-
Labels:None
-
Number of attachments :
Description
BTM is already instrumented for JMX management: you can monitor details of a JDBC connection in each connection pool. This IMHO is a great idea. What it lacks now is any real ability to do something about the pools should something go wrong. For example, you may want to immediately reset one connection pool that has too many connections due to some unexpected glitch. I would like to suggest some extensions to BTM's JMX support:
- Attribute: total number of connections in all connection pools, total and in-pool.
- Attribute: total number of connections for each connection pool.
- Operation: reset all the connections of a specific pool, reducing # of connections to its minSize.
- Operation: reset all connections of all pools, reducing them to their minSizes.
Being able to force a single connection to be closed will be useful as well.
Closing connections via JMX will require some changes in the connection pool. It is currently not possible to force a connection to be closed: the XAResourceHolder's state must be changed but the connection handle is not updated so it will continue to use a connection even if its status says it is back in the pool.
Once this XAResourceHolder / connection handle state mismatch has been fixed and the JMX beans implemented, the next step is to implement another scheduler task that can take back connections if they stayed out of the pool for too long. This would require another config setting like takeBackConnectionTimeout. Another useful feature would be to save a stack trace when a connection is borrowed from the pool and log it when a connection is taken back after timeout expired.