Commons Dbcp
  1. Commons Dbcp
  2. DBCP-11

[dbcp] stmt.getConnection() != Connection used to create the statement

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2
    • Fix Version/s: 1.3
    • Labels:
      None
    • Environment:

      Operating System: other
      Platform: All

      Description

      Hi,

      I'm not an expert in implementing connection pools or jdbc itself. But shouldn't
      the following code work?

      Connection con = pool.getConnection()
      PreparedStatement ps = con.prepareStatement()

      con.equals(ps.getConnection) // returns false!

      Ok, I don't need it to be equal, but the following also does not work:

      ps.getConnection().close()
      con.isClosed() // is false!!!

      That means, if I have a Statment and want to close its connection, I have to
      remember the conncetion. Is that the requested behavior? Because of this my pool
      is running over.

      The java.sql API says that Statment.getConnection() has to be the connection
      which created the statement.

      1. back-pointers.patch
        21 kB
        Dain Sundstrom

        Activity

        Hide
        Phil Steitz added a comment -

        Patch applied. Thanks.

        Show
        Phil Steitz added a comment - Patch applied. Thanks.
        Hide
        Dain Sundstrom added a comment -

        This patch assures that all all returned Statements, PreparedStatements, CallableStatements and ResultSets are wrapped with a delegating object, which already properly handle the back pointers for Connection and Statement. This patch includes an extensive test to assure that the same object used to create the statement or result set is returned from either the getConnection() or getStatementMethod().

        Show
        Dain Sundstrom added a comment - This patch assures that all all returned Statements, PreparedStatements, CallableStatements and ResultSets are wrapped with a delegating object, which already properly handle the back pointers for Connection and Statement. This patch includes an extensive test to assure that the same object used to create the statement or result set is returned from either the getConnection() or getStatementMethod().
        Hide
        Henri Yandell added a comment -

        My vote (with a few minutes thought) is that the Statements should be returning the Connection they came from and not the underlying physical connection. ie) We should change things.

        Show
        Henri Yandell added a comment - My vote (with a few minutes thought) is that the Statements should be returning the Connection they came from and not the underlying physical connection. ie) We should change things.
        Hide
        Phil Steitz added a comment -

        Changing the fix version to 1.3. We may in fact decide on WONTFIX eventually, but I want to hold off on that judgement until we have reworked close() systematically.

        If we interpret the spec to mean that Statment.getConnection() has to return the physical connection that created the statement, this is in general not going to be equal to the connection object that the user has a reference to and may also be open when the user's connection is closed.

        Show
        Phil Steitz added a comment - Changing the fix version to 1.3. We may in fact decide on WONTFIX eventually, but I want to hold off on that judgement until we have reworked close() systematically. If we interpret the spec to mean that Statment.getConnection() has to return the physical connection that created the statement, this is in general not going to be equal to the connection object that the user has a reference to and may also be open when the user's connection is closed.

          People

          • Assignee:
            Unassigned
            Reporter:
            Alexander Rupsch
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development