Neil Edney wrote:
> Hi,
>
> We have implemented a database connection pool class (extract below) and use
> the 'getInstance' method to ensuire that there is only one instance created
> at any one time.
>
> What we need to know is when will this class be destroyed? Is it went the
> server is stopped (or crashed!) or will it timeout after a period of
> non-use?
>
> Regards,
> Neil
>
> public class DbPool extends Object implements java.io.Serializable {
>
> private static DbPool instance;
>
> public static DbPool getInstance(){
> if (instance == null)
> instance = new DbPool();
> return instance;
> }
>
> /** Creates new dbPool */
> private DbPool(){
>
> /** dbPool code */
>
> }
> }
> [...]
Hi :-) from a email in Servlet-List, there is a sample code
for DBConnectionPool in the following link:
http://www.webdevelopersjournal.com/columns/connection_pool.html
and in Jason Hunter's book, from P266, there is also a sample of
ConnectionPool.
I think you need make getInstance() method "synchronized",
please see the first sample.
The following is just my understanding, as a reference:
( I use "MyServlet" to standard for my Servlet class,
I use "MyHelper" to standard for DBConnectionPool)
* the steps:
- the bytecode of MyHelper in MyHelper.class file
(or in a database...)
- it is loaded by a classloader, now we have "a Class
object of MyHelper", now this classloader holds a
reference to this Class object, this Class object itself
is a instance of "the class Class"
- several instances(or only one, for example, SingleTon in
your code) of MyHelper are/is made "from" that Class
object. normally our Servlet holds the reference(s) to
these/this instance(s). But with SingleTon mode, "the Class
object of MyHelper" Also hold a reference to that
OnlyOneInstance of MyHelper with a static field(in your
code, its name is "instance")
- the classloader of MyServlet may be Or may Not be the same
one with that classloader who loads MyHelper. with
jakarta-tomcat-4.0-b1, it depends on Where we put
MyHelper.class(or MyHelper.jar) .
* now there are several cases:
- MyServlet lose/release the reference(s)(for example, after
reloading), now because "the Class object of MyHelper"
Also hold a reference to that OnlyOneInstance of MyHelper
with a static field (its name is "instance"), so "that
OnlyOneInstance" will not be GCed.
- if the classloader of MyHelper is destroied, then
"the Class object of MyHelper" is not there, but perhaps
that OnlyOneInstance is still there(if MyServlet still hold
a reference to it, or if we already put a reference to it into
ServletContext or somewhere else...), now perhaps our
code will get a Exception.
- if the classloader of MyServlet and MyHelper is the same
one, now with jakarta-tomcat-4.0-b1, when MyServlet
is reloaded, the classloader will be destroied, and so,
MyHelper also lose its classloader.
- so if we want to let MyHelper live "Longer" than MyServlet,
perhaps we need to load MyHelper with another classloader
(for example, Shared classloader or "System classloader" or
other)
- another question: if we use classloaderA(for example, an instance
of URLClassLoader) to load MyHelper, and we are sure that
classloaderA will not be destroied, then is it Possible that
classloaderA will "unload" MyHelper and re-load it again?
I am not sure, but I guess perhaps it is not possible. I find
the following in "The Java Language Specification"(Second
Edition): http://java.sun.com/docs/books/jls/
...
12.7 Unloading of Classes and Interfaces
An implementation of the Java programming language may unload
classes. A class or interface may be unloaded if and only if its
defining class loader may be reclaimed by the garbage collector as
discussed in ยง12.6. Classes and interfaces loaded by the bootstrap
loader may not be unloaded.Here is the rationale for the rule given
in the previous paragraph:
Class unloading is an optimization that helps reduce memory use.
Obviously, the semantics of a program should not depend on whether
and how a system chooses to implement an optimization such as class
unloading. To do otherwise would compromise the portability of
programs. Consequently, whether a class or interface has been
unloaded or not should be transparent to a program.
However, if a class or interface C was unloaded while its defining loader
was potentially reachable, then C might be reloaded. One could never
ensure that this would not happen. Even if the class was not referenced
by any other currently loaded class, it might be referenced by some class
or interface, D, that had not yet been loaded. When D is loaded by C's
defining loader, its execution might cause reloading of C.
Rel
