Uploaded image for project: 'Hibernate ORM'
  1. Hibernate ORM
  2. HHH-7902

Replace JDBC proxies with a set of contracts/helpers

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.2.0.CR1, 4.3.0.Beta1
    • Component/s: hibernate-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

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            brmeyer 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
            brmeyer 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
            brmeyer Brett Meyer added a comment -
            Show
            brmeyer 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:
                brmeyer Brett Meyer
                Reporter:
                brmeyer Brett Meyer
                Participants:
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Development