Bug #9906 Connector/J: QueryTimeout is ignored in Statement

Description:
Via com.mysql.jdbc.Statement a query-timeout can be set via setQueryTimeout().
Upon execution of this method, a variable will be set and the same variable can be read via getQueryTimeout(). 
However, this timeout is completely ignored upon further work ...
The variable timeout will never be read.

So any application assuming that the query returns after maximal <timeout> seconds will fail.

How to repeat:
just look at the code ...

Suggested fix:
I would say, either it has to be implemented or a SQLException should be thrown when calling setQueryTimeout().

We can't implement this until the server does. Unfortunately, unlike other methods (such as .cancel()), the APIDOCs or the JDBC specification don't give a lot of information about what a driver should do if the operation is not supported. If we throw an exception in this case, we'll break a lot of applications that call this method that don't really require the timeout to be respected.

Is this a feature planned for the future?
Could you estimate when it will be implemented?

btw: The exception-handling is inconsistent. 
For normal statements no SQLException is thrown (I understand your reasons). But there is the "UltraDevWorkaround"-class, which defines a callable statement. If you call setQueryTimeout() here, you will get a SQLException("Not Supported")

Mark, I am curious, can this not be implemented by?:

1) timeouts less than soTimeout:
long start = System.currentTimeMillis();
while (notEOS)
{
//read data from socket inputstream
if (System.currentTimeMillis()-now>timeout)
  throw new SqlException("timed out");
}

and also by setting the socket's soTimeout (read-timeout, case where socket is not longer valid)?:

sock.setTimeout(timeout*1000);
//start query
try {
//read data
} catch (SocketTimeoutException e) {
  throw new SqlException("timed out");
}
//end query
sock.setSoTimeout(some longer/default value for pools);