7 Replies Latest reply on May 3, 2002 5:06 AM by mgoodall

    Connection pool implementation bug

    mgoodall

      Hi,

      There seems to be a problem with the connection pool implementation. The Statement and ResultSet objects that are obtained from a Connection in a pool are not wrapped well enough. It's possible to get a reference to the real connection and close it! Here's some (contrived) code to demonstrate the problem:

      // Create the database resources
      Datasource datasource = context.lookup("...");
      Connection conn = datasource.getConnection();
      Statement stmt = conn.createStatement();
      ResultSet rs = stmt.executeQuery("...");

      // "Reverse find" the statement and connection
      Statement stmt2 = rs.getStatement();
      Connection conn2 = stmt2.getConnection();

      // Just to demonstrate the class types
      System.out.println(conn);
      System.out.println(conn2);

      // Closes the *real* connection.
      conn2.close();

      The first println shows a wrapped connection i.e. org.jboss.pool.jdbc.xa.wrapper.XAClientConnection. The second println shows a real connection.

      The call to conn2.close() really does closes the connection and presumably does not return it to the pool.

      Cheers, Matt

        • 1. Re: Connection pool implementation bug
          mgoodall

          I forgot to say ... this is using JBoss v 2.4.4 with embedded Catalina v 4.0.1.

          • 2. Re: Connection pool implementation bug
            davidjencks

            I recommend that you don't abuse the wrappers. If you want to do things like that, get a real xa driver. Is there really a situation where you wouldn't know what connection the statement/result set came from?

            At this point I don't see the need to maintain a resultset wrapper to enable your code to work properly. Do you?

            • 3. Re: Connection pool implementation bug
              mgoodall

              The answer to your first question is yes, I do have a situation where I don't know what connection the statement/result set comes from although admittedly it was more out of convenience than anything else. I have now coded around the problem and I prefer the new version anyway.

              I have since tested the behaviour on Websphere 3.5 and 4.0 and the code does "work properly" there.

              I'm not sure that whether the code was good or not actually matters. The fact is that it is relatively easy to destroy the connection pool using the standard JDBC API.

              My personal opinion on this is that Statement.getConnection() should return the Connection that created it. Since a wrapped connection created the statement, the statement should return the wrapped connection. The same is true for a wrapped ResultSet.

              More importantly than my opinion ... surely the current implementation breaks the very abstraction that JBoss is using to implement connection pooling? Ugh, too many implementations in that sentence ;-).

              Cheers, Matt

              • 4. Re: Connection pool implementation bug
                davidjencks

                In principle I agree with you, however my lifetime is not infinite and I don't want to have to maintain another wrapper class with 500,000 delegating methods only one of which does anything. OK I'm exagerating a little bit;-), but I'm not convinced this is a very serious issue. Are you?

                • 5. Re: Connection pool implementation bug
                  mgoodall

                  It's not an issue for me anymore but I do think it's fairly serious. After all, we are talking about closing a connection that is from a pool and never returning the connection to the pool (I presume).

                  Possibly more serious than depleting the pool is that when the connection is closed it performs a commit. That could be half way through a transaction! You get an exception from the container but it's too late by then - the data is corrupt.

                  Let's at least raise a bug for this so that it is documented and can hopefully get fixed sometime. If I get the chance I might even look into it myself.

                  Is the bug list on sourceforge the one to post to?

                  • 6. Re: Connection pool implementation bug
                    davidjencks

                    Yes, sourceforge. Please point out that you kind of have to jump through hoops to get the underlying connection, and that the workaround is to pay attention and just use the connection you started with, or get it back from the wrapped statement, and that fixing it requires a resultset wrapper.

                    • 7. Re: Connection pool implementation bug
                      mgoodall