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] Created: (DERBY-3210) setQueryTimeout should also affect executeBatch
Date Fri, 16 Nov 2007 13:29:43 GMT
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