Hi Dan, thanks for reviewing this patch so quickly.
I am fully aware of and share you concern for the performance impact of creating all the TimerTask objects. It is far from ideal. The problem is that the Timer class forces recreation of TimerTask objects, since these can't be reused; when a TimerTask has run or been cancelled, it is pure waste. Trying to schedule the same task again will cause an exception. If it wasn't for this, we could associate a TimerTask with each StatementContext object.
This performance impact will, however, only affect queries with a timeout value set. As such, it is a tradeoff - you can get timeouts, but that will slow down your execution.
If it turns out that the calls to checkCancellationFlag() seriously affect performance, these calls could be decimated by doing the call only for each n-th row. (It sure will be nice to get that performance regression test, so we'll see the actual impact.) For the time being, I can do some rudimentary testing of this myself.
I agree a separate module for the timer might be overkill. As for the interface, my idea was that more methods than getCancellationTimer() could be added as needs arose for Timers for other purposes. It would be up to the implementing class whether to actually return the same Timer object. I guess it would depend on the duration of the TimerTasks and the responsiveness requirements whether to use multiple Timers or just a single one.
I meant to support milliseconds use internally and seconds at the JDBC API level. I guess it would be more consistent if I used milliseconds in the language PreparedStatement interface as well. And yes, I'll fix throwing an exception on negative timeout values.