[
http://jira.jboss.com/jira/browse/JBAS-2737?page=all ]
Weston Price resolved JBAS-2737.
--------------------------------
Fix Version/s: JBossAS-5.0.0.Beta
Resolution: Done
Added capability to force pool to never destroy connections below min if configured to do
so.
InternalManagedConnectionPool.removeTimedOut() should not destroy
connections below the minimum pool size
---------------------------------------------------------------------------------------------------------
Key: JBAS-2737
URL:
http://jira.jboss.com/jira/browse/JBAS-2737
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JCA service
Affects Versions: JBossAS-4.0.3 SP1
Environment: SUSE Linux, Sun JDK 1.4.2_08 (though this issue would be relevant to
all platforms)
Reporter: Jim Paterson
Fix For: JBossAS-5.0.0.Beta
By default JBoss JDBC connection pools have a 15 minute idle time. Every time the
IdleRemover runs it currently destroys every connection in the pool that has not been used
in the last 15 minutes. It then establishes new connections if necessary to take the pool
back up to its minimum size.
In most cases this behaviour probably doesn't cause problems. However, in our
scenario it does. We are using DB2 and, in some situations, DB2 caches previously compiled
query plans on a per connection basis. One specific example we have is a highly optimized
search stored procedure that uses temporary tables. The IdleRemover is causing roughly 60%
of our calls to this procedure to go through a new connection. This changes the response
time from this stored procedure from ~200ms to ~2seconds as if triggers re-compilations in
the database.
Because of this behaviour we do not want the application server to drop and restore
connections unless they are in error or the pool has grown beyond the minimum size during
a period of peak load.
I can understand that the current implementation protects the application server against
stale connections. However, there are other mechanisms in the JDBC connection pool to
handle this i.e. the the check-valid-connection-sql and
valid-connection-checker-class-name parameters.
Do you agree that the current implementation should be changed?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira