Hibernate ORM
  1. Hibernate ORM
  2. HHH-7902

Replace JDBC proxies with a set of contracts/helpers

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.2.0.CR1, 4.3.0.Beta1
    • Component/s: core
    • Labels:
      None
    • Last commented by a user?:
      true

      Description

      Performance benchmarking has shown that our JDBC proxying (AbstractProxyHandler and subclasses) are a big hotspot.

      Most of their provided functionality fall into fairly well-defined steps. Replace as much proxying as possible with new contracts.

      CHANGES MADE
      org.hibernate.engine.jdbc.internal.proxy completely removed
      JdbcResourceRegistry merged into JdbcCoordinator.
      A few pieces of LogicalConnectionImplementer moved into JdbcCoordinator as well.
      StatementPreparerImpl registers the Statement with JdbcCoordinator.
      StatementPreparerImpl logs PreparedStatement and CallableStatement SQL
      Replaced Statement#close and ResultSet#close calls with JdbcCoordinator#release
      Enforced the use of StatementPreparer instead of Connection's createStatement, prepareStatement, and prepareCall
      Created ResultSetExtractor and used it to replace execute/executeUpdate/executeQuery calls on Statement/PreparedStatement/CallableStatement
      ResultSetExtractorImpl registers the ResultSet with JdbcCoordinator.
      ResultSetExtractorImpl logs Statement SQL
      org/hibernate/test/jdbc/proxies tests updated/refactored to test the new apis

        Activity

        Hide
        Brett Meyer added a comment - - edited

        Emails from Steve Ebersole

        IMO, the problem is really just a matter of better identifying and encapsulating the different phases of building and consuming statements and result sets. So lets use this investigation to start better defining that and maybe leveraging that as the solution.

        First, lets take the case of performing a select query and processing results:

        The first step is identifying that we in fact need to perform a select (or possibly a procedure call returning results) and that there is some form of "result processing" that builds the end result. Today this is all bundled into Loader which is very inflexible in many scenarios (see my "Loader Redesign" proposal[1]). However, for this work think we still need to stay within the Loader design; just saying that I think we can take some of the redesign proposals and apply them with that.
        Next we actually need to build the statement, which might mean preparing a statement or building a callable statement.
        Then we "prepare" the statement in terms of setting timeouts, registering IN/OUT parameters for procedure calls, etc (I realize using the term "prepare" here is confusing with the fact that JDBC calls the statements prepared after creating them; better phrases/terms welcome).
        Then we bind any input parameter values.
        Then we execute the query
        If the query resulted in ResultSets, we apply the "result processors" identified in step 1 to any results.

        I say that this is important because that really is the reason we did proxying - to tie in to each of the above phases in various ways. For example, whenever a Statement is built (step 2) we want to keep track of it as part of the JdbcResourceRegistry, we want to track all ResultSets too. Logging. Etc.

        ...encapsulate each of those steps behind a contract much like what we already do with StatementPreparer. That would still present a single central place to apply the functionality we want at those points.

        Show
        Brett Meyer added a comment - - edited Emails from Steve Ebersole IMO, the problem is really just a matter of better identifying and encapsulating the different phases of building and consuming statements and result sets. So lets use this investigation to start better defining that and maybe leveraging that as the solution. First, lets take the case of performing a select query and processing results: The first step is identifying that we in fact need to perform a select (or possibly a procedure call returning results) and that there is some form of "result processing" that builds the end result. Today this is all bundled into Loader which is very inflexible in many scenarios (see my "Loader Redesign" proposal [1] ). However, for this work think we still need to stay within the Loader design; just saying that I think we can take some of the redesign proposals and apply them with that. Next we actually need to build the statement, which might mean preparing a statement or building a callable statement. Then we "prepare" the statement in terms of setting timeouts, registering IN/OUT parameters for procedure calls, etc (I realize using the term "prepare" here is confusing with the fact that JDBC calls the statements prepared after creating them; better phrases/terms welcome). Then we bind any input parameter values. Then we execute the query If the query resulted in ResultSets, we apply the "result processors" identified in step 1 to any results. I say that this is important because that really is the reason we did proxying - to tie in to each of the above phases in various ways. For example, whenever a Statement is built (step 2) we want to keep track of it as part of the JdbcResourceRegistry, we want to track all ResultSets too. Logging. Etc. ...encapsulate each of those steps behind a contract much like what we already do with StatementPreparer. That would still present a single central place to apply the functionality we want at those points.
        Hide
        Brett Meyer added a comment -
        Show
        Brett Meyer added a comment - Steve Ebersole , I'll start working with this in https://github.com/brmeyer/hibernate-orm/tree/4.1-perf

          People

          • Assignee:
            Brett Meyer
            Reporter:
            Brett Meyer
            Participants:
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development