Our setQueryTimeout() is still a few bricks shy of a load.
The fundamental problem is that the cancel timer is started on the setQueryTimeout() call - not when you actually start to execute a query. That leads to a couple of bugs:
1. If you call setQueryTimeout(5), wait 10 seconds, and call execute(), the cancel timer has already expired, and the statement will be allowed to run forever. Likewise, if you call setQueryTimeout(5), wait 4 seconds, and call execute(), the statement will be canceled after only 1 second.
2. If you call setQueryTimeout on a PreparedStatement, and execute the same statement several times, the timeout only takes affect on the first statement.
3. If you call setQueryTimeout on one Statement, but don't execute it, the timer will still fire, possible on an unrelated victim Statement.
And one more bug:
The run() method in the timer task contains a finally-block that calls killTimer(), but by the time that runs, the PreparedStatement might already have started running a new query, with a new timeout. And the finally-block erroneously cancels the timeout timer on the next query. I was getting spurious failures in the attached testSetQueryTimeoutOnPrepared() test case, which mysteriously went away when I added a simple System.out.println() call between the queries. That was enough of a delay to mask the race condition. The finally-block seems unnecessary to me, the timer has already fired so there's no harm in leaving the object in place until the finally-block in the execute() method removes it.
I created a pull request on github about this. Patch also attached here.