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] > >