Derby
  1. Derby
  2. DERBY-947

Miscellaneous PreparedStatement methods added by JDBC4

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.2.1.6
    • Component/s: JDBC
    • Labels:
      None

      Description

      As described in the JDBC 4 spec sections 13.2 and 3.1.

      This involves building support for JDBC4 methods added to PreparedStatement and not addressed by other JIRAs: isPoolable() and setPoolable().

      1. DERBY-947-v1.diff
        11 kB
        Francois Orsini
      2. DERBY-947-v1.stat
        0.2 kB
        Francois Orsini
      3. DERBY-947-v2.diff
        12 kB
        Francois Orsini
      4. DERBY-947-v2.stat
        0.2 kB
        Francois Orsini

        Activity

        Hide
        Knut Anders Hatlen added a comment -

        Patch looks good!

        I got one failure in derbyall. lang/closed.java produced a diff, but
        it seemed totally unrelated to the patch. A line containing

        ERROR 08006: Database 'wombat' shutdown.

        was printed earlier than expected. Probably a timing issue. At least,
        it wasn't there when I re-ran the test manually.

        The jdbc4 suite ran successfully (Sun JVM 1.6.0-beta2-b74).

        Committed revision 384753.

        Show
        Knut Anders Hatlen added a comment - Patch looks good! I got one failure in derbyall. lang/closed.java produced a diff, but it seemed totally unrelated to the patch. A line containing ERROR 08006: Database 'wombat' shutdown. was printed earlier than expected. Probably a timing issue. At least, it wasn't there when I re-ran the test manually. The jdbc4 suite ran successfully (Sun JVM 1.6.0-beta2-b74). Committed revision 384753.
        Hide
        Francois Orsini added a comment -

        to follow-up on above comments - new changes have been posted as DERBY-947-v2.stat and DERBY-947-v2.diff.

        Show
        Francois Orsini added a comment - to follow-up on above comments - new changes have been posted as DERBY-947 -v2.stat and DERBY-947 -v2.diff.
        Hide
        Francois Orsini added a comment -

        Knut, thanks for the review.

        Good catch - I actually followed some logic which is there all accross the JDBC 4 tests, such as:

        } catch(SQLException e) {
        if(SQLState.NOT_IMPLEMENTED.equals (e.getSQLState()))

        { System.out.println("Unexpected SQLException"+e); }


        }

        which is exposing the same issue...Also I believe the equal expression above should be reversed - it is evaluated to false right now everytime in both client and engine modes...I will fill in a separate JIRA for this (it is independent of the scope of the changes for this JIRA).

        Interestingly enough, the SQL state on the client driver is not always being set - for instance, logic in
        \trunk\java\client\org\apache\derby\client\am\Statement.java

        do not set the sql state upon throwing new sql exceptions - hence the following logic below,
        ...
        throw new SqlException(agent_.logWriter_, "Invalid maxFieldSize value: " + max);
        ...

        will yield to 'null' when retrieving the sql state of a raised exception via SQLException.getSQLState(), hence making it impossible to write a JDBC application which relies on sql state for the client/server mode - we don't have this problem with the embedded driver...This is already reported as part of JIRA-254 which is supposed to address this issue as well.

        I have changed the code to use a sql exception util method in ExceptionUtil class from the shared package to extract the 5 chars sql state out of the message identifier (like embedded does and client should do) - interestingly enough the logic to extract the state our of the msg id is duplicated in trunk\java\engine\org\apache\derby\iapi\error\StandardException.java but it is a different problem and not in the scope of this JIRA.

        Show
        Francois Orsini added a comment - Knut, thanks for the review. Good catch - I actually followed some logic which is there all accross the JDBC 4 tests, such as: } catch(SQLException e) { if(SQLState.NOT_IMPLEMENTED.equals (e.getSQLState())) { System.out.println("Unexpected SQLException"+e); } } which is exposing the same issue...Also I believe the equal expression above should be reversed - it is evaluated to false right now everytime in both client and engine modes...I will fill in a separate JIRA for this (it is independent of the scope of the changes for this JIRA). Interestingly enough, the SQL state on the client driver is not always being set - for instance, logic in \trunk\java\client\org\apache\derby\client\am\Statement.java do not set the sql state upon throwing new sql exceptions - hence the following logic below, ... throw new SqlException(agent_.logWriter_, "Invalid maxFieldSize value: " + max); ... will yield to 'null' when retrieving the sql state of a raised exception via SQLException.getSQLState(), hence making it impossible to write a JDBC application which relies on sql state for the client/server mode - we don't have this problem with the embedded driver...This is already reported as part of JIRA-254 which is supposed to address this issue as well. I have changed the code to use a sql exception util method in ExceptionUtil class from the shared package to extract the 5 chars sql state out of the message identifier (like embedded does and client should do) - interestingly enough the logic to extract the state our of the msg id is duplicated in trunk\java\engine\org\apache\derby\iapi\error\StandardException.java but it is a different problem and not in the scope of this JIRA.
        Hide
        Knut Anders Hatlen added a comment -

        Hi Francois,

        Your code changes look very good, but I have one comment to the test
        code:

        + if (SQLState.ALREADY_CLOSED.equals(sqle.getSQLState()) ||
        + stmtIsClosed) {
        + // All is good and is expected

        SQLState.ALREADY_CLOSED is "XJ012.S". However, it seems like
        sqle.getSQLState() will return "XJ012". (EmbedSQLException invokes
        StandardException.getSQLStateFromIdentifier, which performs
        substring(0, 5) on the SQL state identifier.)

        Would it make sense to replace SQLState.ALREADY_CLOSED with "XJ012"?
        Alternatively, you could define a local constant

        final String ALREADY_CLOSED =
        SQLState.ALREADY_CLOSED.substring(0, 5); // ugh!

        Show
        Knut Anders Hatlen added a comment - Hi Francois, Your code changes look very good, but I have one comment to the test code: + if (SQLState.ALREADY_CLOSED.equals(sqle.getSQLState()) || + stmtIsClosed) { + // All is good and is expected SQLState.ALREADY_CLOSED is "XJ012.S". However, it seems like sqle.getSQLState() will return "XJ012". (EmbedSQLException invokes StandardException.getSQLStateFromIdentifier, which performs substring(0, 5) on the SQL state identifier.) Would it make sense to replace SQLState.ALREADY_CLOSED with "XJ012"? Alternatively, you could define a local constant final String ALREADY_CLOSED = SQLState.ALREADY_CLOSED.substring(0, 5); // ugh!
        Hide
        Francois Orsini added a comment -

        Here are the changes to address JIRA DERBY-947.

        Uploaded DERBY-947-v1.diff which implements PreparedStatement.isPoolable() and
        PreparedStatement.isPoolable() on embedded and client sides.

        Added some test cases to jdbc4/TestPreparedStatementMethods.java.

        There is a FIXME in some of the unit test logic as a reminder to use Statement.isClosed() instead of a local hint when it is implemented as part of JIRA DERBY-953 - Also, the proper SQL State should be checked against to detect if the exception is due to a statement that has already been closed - right now, the proper SQLState for a statement already closed is only set in embedded - There is already a JIRA to fix SQLState on some of the client side classes.

        I have run the jdbc4 suite as well as derbyall on Windows XP / Sun JVM 1.6.0_b72 without errors.

        Let me know of your comments. Thanks.

        Show
        Francois Orsini added a comment - Here are the changes to address JIRA DERBY-947 . Uploaded DERBY-947 -v1.diff which implements PreparedStatement.isPoolable() and PreparedStatement.isPoolable() on embedded and client sides. Added some test cases to jdbc4/TestPreparedStatementMethods.java. There is a FIXME in some of the unit test logic as a reminder to use Statement.isClosed() instead of a local hint when it is implemented as part of JIRA DERBY-953 - Also, the proper SQL State should be checked against to detect if the exception is due to a statement that has already been closed - right now, the proper SQLState for a statement already closed is only set in embedded - There is already a JIRA to fix SQLState on some of the client side classes. I have run the jdbc4 suite as well as derbyall on Windows XP / Sun JVM 1.6.0_b72 without errors. Let me know of your comments. Thanks.

          People

          • Assignee:
            Francois Orsini
            Reporter:
            Rick Hillegas
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development