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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
