When tomcat is stopped the connection is closed. I'll probably submit
the example to bugzilla. Can somebody familiar with the code suggest
which catalina object keeps a reference of the datasource (beside
being registered in JNDI)?

On 10/26/05, Steve Kirk <[EMAIL PROTECTED]> wrote:
>
> Your code and config below look fine to me, conns seem to be returned OK to
> pool as you say.  Sounds to me like the pool itself leaves the database with
> hanging conns in the pool when it goes down.
>
> When you say "If I deploy/undeploy several times" do you stop and restart TC
> between undeploy and redeploy?  If so, might be worth trying to see whether
> the problem still happens if you stop and restart TC cleanly rather than
> redeploying the webapp while TC is running?  Might help narrow down the
> cause slightly.  Might be worth reporting to bugzilla?
>
> > -----Original Message-----
> > From: Bogdan Calmac [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday 26 October 2005 02:18
> > To: users@tomcat.apache.org
> > Subject: DBCP connection leak after undeploy
> >
> >
> > I've written a simple web application consisting of a servlet which
> > does a select from a table and displays the result. It is then
> > packaged as a war and deployed using the tomcat ant task. After
> > executing the servlet, it is undeployed using the ant task again.
> > stdout confirms that the webapp is deployed and undeployed without
> > errors. The problem is that the connection to the DB is left open even
> > after undeploy.
> >
> > Software used:
> >  - tomcat 5.5.9 on Windows
> >  - DBCP connection pool
> >  - MSSQL server
> >
> > The datasource is defined in META-INF/context.xml with:
> >
> >   <Resource name="jdbc/default" auth="Container"
> > type="javax.sql.DataSource"
> >                maxActive="5" maxIdle="2" maxWait="10000"
> >                username="sa" password="sa"
> >                driverClassName="net.sourceforge.jtds.jdbc.Driver"
> >                url="jdbc:jtds:sqlserver://localhost/pubs"/>
> >
> > and then referenced in WEB-INF/web.xml with:
> >
> >   <resource-ref>
> >       <description>DB Connection</description>
> >       <res-ref-name>jdbc/default</res-ref-name>
> >       <res-type>javax.sql.DataSource</res-type>
> >       <res-auth>Container</res-auth>
> >   </resource-ref>
> >
> > The code accessing the database is:
> >
> >     private long getTitlesCount() {
> >       Connection conn = null;
> >       Statement stmt = null;
> >       ResultSet rs = null;
> >       try {
> >         InitialContext cxt = new InitialContext();
> >         DataSource ds = (DataSource) cxt.lookup(
> > "java:/comp/env/jdbc/default" );
> >         conn = ds.getConnection();
> >         stmt = conn.createStatement();
> >         rs = stmt.executeQuery("select count(*) from titles");
> >         if (rs.next())
> >           return rs.getLong(1);
> >
> >       }
> >       catch(Exception e) {
> >         System.out.println("Failed to retrive title count
> > from the DB.");
> >         e.printStackTrace();
> >       }
> >       finally {
> >         if (rs != null) try { rs.close(); } catch (Exception e) {}
> >         if (stmt != null) try { stmt.close(); } catch (Exception e) {}
> >         if (conn != null) try { conn.close(); } catch (Exception e) {}
> >       }
> >       return -1;
> >     }
> >
> >
> > If I deploy/undeploy several times, the number of leaked connections
> > is incremented with 1 each time.
> >
> > If I execute the servlet several times, the number of connections
> > remains constant, which confirms that the servlet releases the
> > connection properly.
> >
> > My guess is that the datasource is not tied to the webapp and it is
> > not notified/released when the webapp is undeployed.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to