commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elifarley Callado Coelho Cruz <elifar...@gmail.com>
Subject Re: stmt.getConnection() != Connection used to create the statement
Date Wed, 17 Aug 2005 21:17:37 GMT
I have the same problem while using dbcp with OC4J. Are you using it ?


On 8/17/05, Alexander Rupsch <Alexander.Rupsch@gmx.de> wrote:
> 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: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message