Thanks for that.
I will have a look at the Listener.
As for your other comments:
- the class is in a package in the classes directory
- the application does not close connections. It used to rely on the
connection pool being garbage collected. Therefore the
Connection finalize would close the connection.
I still don't understand how I can end up with two instances of a singleton class.
Servlets call a getInstance method. This creates a new instance if one does not
already exist. If a servlet is reloaded and the pool
is not then the servlet should get the existing pool. If the pool is reloaded too then
the old one should be garbage collected.
> >
> > I am currently porting a web application from JServ to Tomcat 4.0.1
> > and have run into a problem.
> >
> > The application maintains a database connection pool in a singleton
> > utility class. When I change another class the auto reload eventually
> > picks this up but this class goes and creates a new connection pool
> > even though the old one has not been destroyed.
> >
>
> It sounds like you might want to destroy the old connection pool when the
> application is reloaded (or when Tomcat is shut down).
>
> An easy way to deal with this is to use the new "ServletContextListener"
> APIs from Servlet 2.3 (see the spec at
> <http://java.sun.com/products/servlet/download.html> for more info).
> Basically, you create a class that implements ServletContextListener, and
> register it in the web.xml file. Then, the contextInitialzed() method
> gets called when the application is started (either because you started
> Tomcat normally or after a restart), and contextDestroyed() is called when
> the app is shut down (or before a reload).
>
> Create your connection pool in the contextInitialized() method, and close
> it in contextDestroyed().
>
> > The upshot is that the number of connections steadily grows while I am
> > developing until the database gives up.
> >
> > Under JServ I understood that when a class was changed the whole zone
> > was reloaded. What goes on with Tomcat when it reloads? Are there
> > issues of threading here?
> >
>
> This is still true -- but there's a couple of things that might be going
> on:
>
> * Where is your connection pool class loaded from? If it's
> in the "lib" directory, those classes do *not* get reloaded.
>
> * Did your application ever close the old connections?
>
> > (I am running on Solaris 2.8 with JDK 1.2.2)
> >
> > David Bell
> > mailto:[EMAIL PROTECTED]
> >
>
> Craig
>
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
