tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Stor <mar...@frightanic.com>
Subject RE: Tomcat reload / classloader / connection pool
Date Wed, 03 Dec 2003 01:09:13 GMT
Justin Ruthenbeck wrote:
> At 04:21 PM 12/2/2003, you wrote:
> > Christopher Schultz wrote:
> > 
> > > > First of all, why is this so?
> > > 
> > > This is likely because of the way you use the singleton. When you
> > > have a "singleton" (I use quotes because it's probably not a real
> > > singleton.... otherwise we would not be having this discussion)
> > > the static data is associated with the java.lang.Class object
> > > that gets created when your class is loaded. When the re-load
> > > occurs, that static data sticks around. The new classloader used
> > > for the new context loads a new copy of the "singleton" and they
> > > pile up over time. You need to shutdown the connection pool
> > > before the context dies.
> > 
> > I understand it sticks around because the data is independent of
> > the any object. But eventually even this static data should get
> > garbage collected. 
> > 
> > Well, if this is not a GoF-Singleton what is it then...?
> 
> It's a Singleton only for the (temporary) ClassLoader in which it was
> created.  In other words, it's not a "real" Singleton because multiple
> copies can exist in a given JVM.

[OT]
Ok, this is certainly true. It's a Singleton from the classloader's
point of view. Is there even a secure way to have a JVM-wide Singleton?

> > public class ConnectionFactory {
> >     private static Logger logger =
> > Logger.getLogger("ConnectionFactory");
> >     private static ConnectionFactory instance;
> >     //stores references to all connection managers (connection
> >     pools) private final Hashtable managers = new Hashtable();
> > 
> >     private ConnectionFactory() {
> >         //foo
> >     }
> >     public static ConnectionFactory getInstance() {
> >         if (null == instance) {
> >             instance = new ConnectionFactory();
> >         }
> >         return instance;
> >     }
> > }
> > 
> > > > Second of all, how can I prevent this? Somehow listen for
> > > > reloads and react appropriately?
> > > 
> > > Yes. Consider writing a ServletContextListener and "closing" the
> > > pool before the context goes down. It will be run when the new
> > > context comes up, too. 
> > > 
> > > Check the documentation for javax.servlet.ServletContextListener
> > 
> > I've just gone through its description. Looks my friend for this
> > problem.
> 
> ServletContextListener is the standard way to address problems such as
> this.  You alluded to possibly moving your ConnectionFactory.class to
> Tomcat's lib (or similar) directory to make it available to all
> webapps 
> -- this isn't necessarily a bad idea, depending on what you want to
> accomplish, but it is an "advanced" configuration and you should fully
> understand the ClassLoading system before getting involved in it.

After I've managed to understand what "alluded" means (I'm non-native as
you might have figured) I should get along with this ;-))
Seriously, putting it into the standard CLASSPATH should fix the
conflict with multiple classloaders, but will cause other - probabely
more serious - trouble.

Christopher, Justin, thanks for your kind help. It's greatly
appreciated; especially so late at night (it's after 2am over here).

Marcel


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


Mime
View raw message