Uploaded image for project: 'Application Server 3  4  5 and 6'
  1. Application Server 3 4 5 and 6
  2. JBAS-2737

InternalManagedConnectionPool.removeTimedOut() should not destroy connections below the minimum pool size

    XMLWordPrintable

Details

    • Feature Request
    • Resolution: Done
    • Major
    • JBossAS-5.0.0.Beta1
    • JBossAS-4.0.3 SP1
    • JCA service
    • None
    • 0
    • 0% 0%

    Description

      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?

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              jim.paterson Jim Paterson (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: