commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Rupsch <>
Subject Re: stmt.getConnection() != Connection used to create the statement
Date Wed, 17 Aug 2005 21:05:33 GMT
Hello Alexander,

> I cant tell what pool technology you are using and in what specific
> environment. But in general, pools do the handling for you. They
> implement connection reuse: that is, the connnection is only closed
> virtually (e.g. freed for reuse) and not closed physically to improve
> performance. 

Well, of course, but I have to tell the pool that I don't want to use
the connection anymore. So if I ask the pool for a connection I have to
call close() to show that I'm ready.

In my case I ask for a connection and then I use it to drive several
queries. to create, use and close the statement I use only one method
with different sqls. the return of the statement looks like this:

      Connection conn = null;
         conn = stmt.getConnection();
      } catch (SQLException e)
         throw new DAOException(e);
         DBUtil.cleanUp(conn, stmt);

cleanUp() first close the stmt an then the connection. this works well
if I remember the connection which created the statement, but not if I
ask the statement for its creator to close it.

I can go around this problem very easy by using the "remember the con by
myself" workaround, but I was wondering about the current
implementation. You can see this behavior in dbcp and in dbpool (can't
find the link right now) and this makes me wonder....

I also could take a look in the statement pooling feature and don't even
use a connection., but this wouldn't clarify the problem.

Well, if I find the time, I'll write a little unit test to show what I
mean. That way I can also preclude the side effect of the integration of
dbcp in our application.

Alexander Rupsch

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message