https://issues.apache.org/bugzilla/show_bug.cgi?id=54693
--- Comment #3 from Daniel Mikusa <dmik...@vmware.com> --- Comments inline below... >Only one comment: since a value of "0" disabled query timeout (it will wait >forever), why not make the default 0 instead of -1? I implemented it the same way as DBCP to try and make it as compatible as possible. In my implementation (same as DBCP), the value must be greater than 0 or the connection pool code won't call "setQueryTimeout", which means that by default the connection pool won't call "setQueryTimeout". I like this approach because it won't change anything by default. In other words, the query timeout value would default to what is specified by the JDBC driver or perhaps by a driver specific setting. I'm open to other suggestions though. >Also, you mention that QueryTimeoutInterceptor will modify the query timeouts >of all queries... how does it interact with this patch? Sorry, I was under the impression based on some comments I read on a previous bug that the QueryTimeoutInterceptor would set the query timeout for a validation query. I tested this a bit and it turns out to not be true. In my tests, I saw that the validation query is executed against the underlying Connection, not the ProxyConnection. Because it runs against the underlying Connection, this means that the interceptors are not executed against it. >Will QueryTimeoutInterceptor set the query timeout and then your code re-sets >the query timeout (presumably to a different value)? If that's the case, what >happens when validationQueryTimeout=0 and you are using the >QueryTimeoutInterceptor? A reasonable user might expect that the validation >query would /never/ time out, but the QueryTimeoutInterceptor would affect it. As I mentioned above, the QueryTimeoutInterceptor and validationQueryTimeout should not affect each other. Just to be sure, I added a test case to check this. Attaching new patch with that test case added. Dan -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
