| Summary: | In case of invalid or empty slqQuery connection are always invalidated without usefull information | ||
|---|---|---|---|
| Product: | Tomcat Modules | Reporter: | olamy <olamy> |
| Component: | jdbc-pool | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alex-pub.apache-ant |
| Priority: | P2 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
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. > 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 |
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.