Yes, it should be OK if you close the pool connection at the
appropriate time and don't close the one from getInnermostDelegate -
the pool takes care of that one.
--
Len
On Feb 18, 2008 2:48 PM, Petter Olofsson <[EMAIL PROTECTED]> wrote:
> Hi Len! Thanks for the reply.
> The dconn was closed by simply calling the close function when I was
> done with the connection.
> This is something that has worked in the past so I'm a bit confused
> when it stopped working now.
>
> I have solved the problem now by just returning the connection from
> the pool and close it later. The connection returned by calling
> getInnermostDelegate() is not closed at all. Does anyone know if this
> will cause problem later on? It seems to work correctly for now with a
> connection pool consisting of only one connection.
>
>
> 2008/2/18, Len Popp <[EMAIL PROTECTED]>:
>
> > It looks to me like you're bypassing the connection pool and messing
> > up the way it handles connections. You've only shown a snippet of
> > code, so I have a couple of questions:
> > 1. After dconn is returned from getConnection, how and when does it get
> > closed?
> > 2. Does the exception happen every time getConnection is called, or
> > does it maybe succeed on the first call and fail during the second?
> >
> > When you get a connection from the connection pool, you're supposed to
> > close it *after* you use it. At
> > that time the underlying "real" connection is *not* closed, it's just
> > returned to the pool. That's the point of the connection pool, it
> > keeps a set of connections open to reduce overhead. Here you're
> > closing the PoolableConnection immediately, before it's used, which is
> > wrong.
> >
> > Here's what I think happens. (This is partly guesswork.)
> >
> > - DatabaseController.getConnection gets a PoolableConnection, extracts
> > the underlying real connection (dconn), then returns the
> > PoolableConnection to the pool.
> >
> > - The caller of DatabaseController.getConnection uses the real
> > connection and then closes it.
> >
> > - Now the pool contains a PoolableConnection whose underlying
> > connection is closed - This shouldn't happen!
> >
> > - DatabaseController.getConnection is called a second time, and
> > returns the same PoolableConnection as before (because it's back in
> > the pool).
> >
> > - conn.close() fails this time because the underlying connection was
> > closed prematurely.
> >
> > Normally you'd never call getInnermostDelegate, you'd just use the
> > PoolableConnection returned by DataSource.getConnection and close it
> > when you're done. Is there a reason that you can't do that?
> > --
> > Len
> >
> >
> > On Feb 18, 2008 11:05 AM, Petter Olofsson <[EMAIL PROTECTED]> wrote:
> > > Hello tomcat users!
> > >
> > > I have a problem using the connection pool in Tomcat. The function
> > > getConnection() throws the following error message:
> > >
> > > [Error message]
> > > When trying to get a Connection an SQLExcpetion occurred:
> > > java.sql.SQLException: Already closed.
> > > at
> > > org.apache.tomcat.dbcp.dbcp.PoolableConnection.close(PoolableConnection.java:84)
> > > at
> > > org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:181)
> > > at
> > > org.metria.kiruna.profs.eniro.db.DatabaseController.getConnection(DatabaseController.java:136)
> > >
> > > [DatabaseController.java]
> > > protected Connection getConnection(){
> > > try{
> > > Context initContext = new InitialContext();
> > > Context envContext =
> > > (Context)initContext.lookup("java:comp/env");
> > > DataSource ods = (DataSource) envContext.lookup("jdbc/yyy");
> > >
> > > Connection conn = ods.getConnection();
> > >
> > > Connection dconn = ((DelegatingConnection)
> > > conn).getInnermostDelegate();
> > >
> > > // if( conn != null && !conn.isClosed() ) // Line 135
> > > conn.close(); // Line 136
> > >
> > > return dconn;
> > > }catch( SQLException sqle ){
> > > System.err.println("When trying to get a Connection an
> > > SQLExcpetion occured.");
> > > sqle.printStackTrace();
> > > }catch( NamingException ne ){
> > > System.err.println("When trying to get a Connection an
> > > NamingException occured.");
> > > System.err.println(ne);
> > > }
> > > return null;
> > > }
> > >
> > > [Context.xml]
> > > <Resource accessToUnderlyingConnectionAllowed="true"
> > > auth="Container"
> > > driverClassName="oracle.jdbc.OracleDriver"
> > > maxActive="30"
> > > maxIdle="10"
> > > maxWait="1000"
> > > name="jdbc/yyy"
> > > username="xxx"
> > > password="xxx"
> > > type="javax.sql.DataSource"
> > > url="jdbc:oracle:thin:@drone:1521:top" />
> > >
> > > If the outer connection is left open ( line 135, 136 is deleted) then
> > > all connections are used until "maxActive" connections are created.
> > >
> > > The program uses Tomcat 5.5.26 and Oracle 10.2.3.0.
> > >
> > > Does anybody have an idea of why I can't close the outer connection so
> > > that the connections can be returned to the pool when I am done?
> > >
> > > / Petter
> > >
> > > ---------------------------------------------------------------------
> > > To start a new topic, e-mail: users@tomcat.apache.org
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To start a new topic, e-mail: users@tomcat.apache.org
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Petter Olofsson
>
> Student vid civilingenjörsprogrammet Interaktion och Design
> på Umeå Universitet
>
> Telefon: +46 (0)70 369 36 77
> ICQ: 153888597
> Msn: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
