db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dyre Tjeldvoll (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3210) setQueryTimeout should also affect executeBatch
Date Sat, 17 Nov 2007 21:22:43 GMT

    [ 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.


Mime
View raw message