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.
- Heikki
