Bug 50860 - In case of invalid or empty slqQuery connection are always invalidated without usefull information
Summary: In case of invalid or empty slqQuery connection are always invalidated withou...
Status: RESOLVED FIXED
Alias: None
Product: Tomcat Modules
Classification: Unclassified
Component: jdbc-pool (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-03 06:51 UTC by olamy
Modified: 2012-03-20 17:33 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description olamy 2011-03-03 06:51:14 UTC
The code is (in PooledConnection.java#validate(int validateAction,String sql) )
        Statement stmt = null;
        try {
            stmt = connection.createStatement();
            stmt.execute(query);
            stmt.close();
            this.lastValidated = now;
            return true;
        } catch (Exception ignore) {
            if (log.isDebugEnabled())
                log.debug("Unable to validate object:",ignore);
            if (stmt!=null)
                try { stmt.close();} catch (Exception ignore2){/*NOOP*/}
        }
        return false;

So in the case of null or invalid query (connection is always invalidated : seems normal :-) ).
But without any usefull message (except if you use debug : but seems complicated in a production env).
So IMHO adding a log.warning in case of null query could be usefull.
Comment 1 Alexander Pogrebnyak 2011-10-19 16:57:10 UTC
Although it seems similar to Bug 50660, the case of a `null` query is really a misconfiguration error.

I think it should be treated differently from "invalid" SQL case and in case of `null` query throw RuntimeException that tells the user about misconfiguration.

I also think that obvious configuration validation (validationQuery is null or empty, when validation is enabled ) has to happen when the connection is initialized (or better yet in ConnectionPool.init), because in my test it would not happen before the validationInterval would have expired, and a one-off message in the middle of log stream does not call to much attention.
Comment 2 Filip Hanik 2012-03-20 17:33:53 UTC
> I also think that obvious configuration validation (validationQuery is null or
> empty, when validation is enabled ) has to happen when the connection is

that would be a separate issue, feel free to open bugzilla issue


This has been fixed in by adding a configuration option called logValidationErrors="true|false" in r1303031