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;
try
{
conn = stmt.getConnection();
} catch (SQLException e)
{
throw new DAOException(e);
}finally
{
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.
regards.
--
Alexander Rupsch
http://www.dreinhalb.de
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
