I haven't done extensive research, but I think the JDBC way of doing this would be to use Statement.cancel()... Otherwise my guess is different drivers would do different things, and you definitely want the driver to tell the server to cancel if the protocol allows it to do so.

That means having Lucee's Controller thread be smarter than just sending Thread.interrupt(). Perhaps cfquery needs to save a reference to the running Statement somewhere the Controller thread can access it - perhaps wrapped in a Strategy pattern... Something like RequestTimeoutAction.

Nice. That's exactly what I had in mind.

Can't we cancel the query by calling interrupt() on the thread if it times out (from the Controller thread)? And that way avoid the driver's creation of a monitor thread?

https://github.com/lucee/Lucee/blob/5.1/core/src/main/java/lucee/runtime/tag/Query.java#L470

search the code for "remaining", you will see that we did calculate the remaining request timeout and set this ALWAYS with statement. Problem was that some drivers start a new thread in that case, what caused problems if a lot of queries are executed.
so we disabled this for the moment and we have to review and make it smarter.

I usually don't use query timeouts because it spawns monitoring threads in the JDBC drivers. I'm used to the ACF behavior of once a query starts, you're in it until the query finishes. (at which point the next tag may throw a request timeout)

If we're going to look at something like this, we need also examine other areas where external data is requested... cfhttp, cfpop, cfimap, etc.

Further, were we to implement this, since this behavor is != ACF you'd definitely want to wrap this in a server option.

In my opinion I wouldn't use this; I'd use querytimeouts on the datasource instead. (or not at all, because I monitor my SQL query runtimes to detect SQL issues)