[
https://issues.apache.org/jira/browse/DERBY-3210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543313
]
Dyre Tjeldvoll commented on DERBY-3210:
---------------------------------------
This is only a problem in the ClientDriver. In embedded mode this works as
expected. That is; if the batch as a whole exceeds the time limit, an exception
is thrown. Getting the same behavior with the ClientDriver should be as simple
as sending the timeout value in flowExecuteBatch(), in the same way that it is
currently done in flowExecute().
> setQueryTimeout should also affect executeBatch
> -----------------------------------------------
>
> Key: DERBY-3210
> URL: https://issues.apache.org/jira/browse/DERBY-3210
> Project: Derby
> Issue Type: Improvement
> Affects Versions: 10.3.1.4
> Reporter: Dyre Tjeldvoll
> Priority: Minor
>
> The current implementation of setQueryTimeout follows the description in the
> javadoc (Java 6, JDBC 4.0) which says: "A JDBC driver must apply this limit
> to the execute, executeQuery and executeUpdate methods. " But in the actual
> specification document (JSR -000221, final version, section 13.1.3 page 97)
> states: "A JDBC driver must apply this limit to the execute, executeBatch,
> executeQuery and executeUpdate methods."
> In Derby, a statement which times out when executed with Statement.execute(),
> will NOT time out if executed with executeBatch().
> Example:
> s.execute("CREATE TABLE T1(I INT, J VARCHAR(10))");
> s.execute("INSERT INTO T1 VALUES (1, 'TWO^ZERO')");
> s.execute("INSERT INTO T1 VALUES (2, 'TWO^ONE')");
> s.execute("INSERT INTO T1 VALUES (4, 'TWO^TWO')");
> s.execute("INSERT INTO T1 VALUES (8, 'TWO^THREE')");
> s.execute("INSERT INTO T1 VALUES (16, 'TWO^FOUR')");
> s.execute("INSERT INTO T1 VALUES (32, 'TWO^FIVE')");
> s.execute("CREATE TABLE T2(I INT, J VARCHAR(10))");
> commit();
> s.setQueryTimeout(1);
> assertStatementError("XCL52", s,
> "INSERT INTO T2 SELECT * FROM T1 WHERE I = GET_SLOW(I)");
> will work, but
> Statement s = createStatement();
> s.execute("CREATE TABLE T1(I INT, J VARCHAR(10))");
> s.execute("INSERT INTO T1 VALUES (1, 'TWO^ZERO')");
> s.execute("INSERT INTO T1 VALUES (2, 'TWO^ONE')");
> s.execute("INSERT INTO T1 VALUES (4, 'TWO^TWO')");
> s.execute("INSERT INTO T1 VALUES (8, 'TWO^THREE')");
> s.execute("INSERT INTO T1 VALUES (16, 'TWO^FOUR')");
> s.execute("INSERT INTO T1 VALUES (32, 'TWO^FIVE')");
> s.execute("CREATE TABLE T2(I INT, J VARCHAR(10))");
>
> s.addBatch("INSERT INTO T2 SELECT * FROM T1 WHERE I = GET_SLOW(I)");
> s.setQueryTimeout(1);
> try {
> s.executeBatch();
> fail("Execution of the batch should time out"); // <-- fails here
> } catch (SQLException e) {
> assertSQLState("XCL52", e);
> }
> will fail
> (GET_SLOW() is a function that returns its argument after argument seconds.
> Since the spec and the javadoc differ, I have classified this as an
> improvement, rather than a bug.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
