OpenJPA
  1. OpenJPA
  2. OPENJPA-2123

Minor performance improvements for Connection and ResultSet processing

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.1, 2.3.0
    • Fix Version/s: 2.2.1, 2.3.0
    • Component/s: jdbc, performance
    • Labels:
      None

      Description

      Came across a few items that could help with performance in certain scenarios. I'll document each one as I determine the proper resolution. The first one is that we were preparing the ability to print the SQL parameters even if no configuration properties were set requesting that capability. This resulted in String and StringBuffer operations that were extra overhead on every interaction with the Connection.

      More to come...

        Activity

        Hide
        Kevin Sutter added a comment -

        Found another minor improvement that is indirectly related to Connection and ResultSet processing... Whenever setQueryTimeout is processed with the DB2Dictionary, we make a call to a private method to determine the level or version of DB2 that we're talking with. This method is expensive due to the string manipulation that is performed. Since we have already determine the level of DB2 during the connectedConfiguration() initialization, we can be more efficient by just checking the value of db2ServerType instead of calling isDB2ZOSV8xOrLater().

        Show
        Kevin Sutter added a comment - Found another minor improvement that is indirectly related to Connection and ResultSet processing... Whenever setQueryTimeout is processed with the DB2Dictionary, we make a call to a private method to determine the level or version of DB2 that we're talking with. This method is expensive due to the string manipulation that is performed. Since we have already determine the level of DB2 during the connectedConfiguration() initialization, we can be more efficient by just checking the value of db2ServerType instead of calling isDB2ZOSV8xOrLater().
        Hide
        Kevin Sutter added a comment -

        There may be occasions where String columns in a database contain large amounts of unnecessary trailing whitespace. To alleviate the movement and processing of this whitespace, I am introducing a DBDictionary property to optionally trim this trailing whitespace after retrieving a String field from a ResultSet. The default value for this new property (DBDictionary.trimStringColumns) will be "false" to allow existing applications to continue executing as they have today. But, for those applications where the removal of this whitespace can provide a performance benefit, this property can be set to "true" and then trim() will be called on the String result before returning it to the Entity.

        Show
        Kevin Sutter added a comment - There may be occasions where String columns in a database contain large amounts of unnecessary trailing whitespace. To alleviate the movement and processing of this whitespace, I am introducing a DBDictionary property to optionally trim this trailing whitespace after retrieving a String field from a ResultSet. The default value for this new property (DBDictionary.trimStringColumns) will be "false" to allow existing applications to continue executing as they have today. But, for those applications where the removal of this whitespace can provide a performance benefit, this property can be set to "true" and then trim() will be called on the String result before returning it to the Entity.

          People

          • Assignee:
            Kevin Sutter
            Reporter:
            Kevin Sutter
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development