If you implement a JdbcInterceptor, the method JdbcInterceptor.disconnected
will always be called.
If the disconnect is permanent, then JdbcInterceptor.reset(null,null) will
be called after disconnected
On Tue, Sep 23, 2014 at 9:41 AM, Todd Chapman <t...@chaka.net> wrote:
> Hi,
>
> My application uses the Tomcat JDBC pool. While using netstat and tcpdump
> to diagnose connection problems I noticed that the client side occasionally
> closes a DB connection and opens a new one. That is unexpected based on my
> configuration.
>
> poolProperties.setInitialSize(10);
> poolProperties.setMinIdle(10);
> poolProperties.setMaxActive(100);
> poolProperties.setMaxIdle(100);
> poolProperties.setMaxWait(10000);
> poolProperties.setTimeBetweenEvictionRunsMillis(30000);
> poolProperties.setMinEvictableIdleTimeMillis(30000);
> poolProperties.setTestWhileIdle(false);
> poolProperties.setTestOnBorrow(true);
> poolProperties.setValidationQuery("SELECT 1 AS data");
> poolProperties.setValidationInterval(3);
> poolProperties.setLogValidationErrors(true);
> poolProperties.setTestOnReturn(false);
> poolProperties. maxAge(0);
>
> I would expect the pool size to never shrink based on this configuration.
> Well maybe if borrow test fails but no validation errors are being logged.
>
> How can I figure out where close() is being called on the physical DB
> connection? I tried writing a JdbcInterceptor but it's disconnected()
> method gets called on the PooledConnection, not the physical connection.
>
> Does Tomcat JDBC Pool implement javax.sql.ConnectionEventListener
> interface?
>
> Thanks you for any help,
>
> -Todd
>
