RE: [Proxool-developer] Bug 673073

[Martin C. <mus...@us...>]

> The real problem is shutting down the pool on application reloads. Our
> current implementation of this has been proved to be very unpredicable, so I
> think we need to document *very clearly* that all applications that expect
> to be reloaded must shutdown proxool in some kind of container spesific
> manner. As you mention, Servlet.destroy() is a good place to do this in a
> servlet container. Most other environments will hopefully also provide
> something similar (like Disposable.dispose() in a Avalon container).

I know, I've stated my thoughts on this before, but again I'll restate
it: Proxool should not be installed at an individual web application
level, but at the common classloader level. 

You want one instance of proxool per VM to ensure the Singleton pattern
is enforced. By deploying the JAR with each individual application, you
end up creating multiple instances of the Proxool framework. Thus
breaking the Singleton pattern.

Imagine a Servlet container connecting to the same database for several
different web applications. You would not benefit from the beauty of
managing your pools efficiently across all applications. 

Additionally, of course, you break the transparency by forcing Servlet
developers to write proxool specific code within their Servlet
application. And which Servlet would I write this "destroy" code if my
web application has multiple Servlets? Proxool is most effective because
of its transparency, I say we should foster this transparency.

My 0.5 cents (Canadian dollar isn't doing to well)
Martin