Satheesh Bandaram (JIRA) wrote:
2) What would happen if a 10.2 client tries to send a SET STATEMENT_TIMEOUT
statement to a 10.1 server? There doesn't seem to be any mechanism to prevent
unpleasant events.
I was reviewing the patch and decided to look into your question more, and I
think there is actually code there to catch this. The choice of a "SET ..."
syntax was a good one in this particular case: there is already code in
DRDAConnThread that looks for "SET ..." statements that are included as part of
an EXCSQLSET command, and if the statement isn't recognized, the server will
simply return a warning and ignore it. The code that does this is in the
"parseEXCSQLSETobjects()" method:
...
try {
drdaStmt.getStatement().executeUpdate(sqlStmt);
} catch (SQLException e) {
// if this is a syntax error, then we take it
// to mean that the given SET statement is not
// recognized; take note (so we can throw a
// warning later), but don't interfere otherwise.
if (e.getSQLState().equals(SYNTAX_ERR))
hadUnrecognizedStmt = true;
else
// something else; assume it's serious.
throw e;
}
break;
...
// Now that we've processed all SET statements (assuming no
// severe exceptions), check for warnings and, if we had any,
// note this in the SQLCARD reply object (but DON'T cause the
// EXCSQLSET statement to fail).
if (hadUnrecognizedStmt) {
SQLWarning warn = new SQLWarning("One or more SET statements " +
"not recognized.", "01000");
throw warn;
} // end if.
...
To confirm, I tried to run jdbcapi/SetQueryTimeoutTest from a client that had
the patch applied against a server that did not. The result was the following
diff, which looks correct to me:
> Test SetQueryTimeoutTest FAILED
>
org.apache.derbyTesting.functionTests.tests.jdbcapi.SetQueryTimeoutTest$TestFailedException:
fetch did not time out. Highest execution time: 7000 ms
In other words, the call to "SET QUERY_TIMEOUT" failed with a syntax error and
was ignored, and thus the statement never timed out.
Does that sound correct?
Army
