db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3210) setQueryTimeout should also affect executeBatch
Date Fri, 14 Dec 2007 16:47:44 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kathey Marsden updated DERBY-3210:
----------------------------------

    Component/s: JDBC

> setQueryTimeout should also affect executeBatch
> -----------------------------------------------
>
>                 Key: DERBY-3210
>                 URL: https://issues.apache.org/jira/browse/DERBY-3210
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC
>    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