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.
Reloading may not be transparent if, for example, the class has:
Static variables (whose state would be lost).
Static initializers (which may have side effects).
Native methods (which may retain static state).
Furthermore the hash value of the Class object is dependent on its
identity. Therefore it is, in general, impossible to reload a class
or interface in a completely transparent manner. Since we can
never guarantee that unloading a class or interface whose loader is
potentially reachable will not cause reloading, and reloading is never
transparent, but unloading must be transparent, it follows that one
must not unload a class or interface while its loader is potentially
reachable. A similar line of reasoning can be used to deduce that
classes and interfaces loaded by the bootstrap loader can never be
unloaded.
One must also argue why it is safe to unload a class C if its defining
class loader can be reclaimed. If the defining loader can be reclaimed,
then there can never be any live references to it (this includes references
that are not live, but might be resurrected by finalizers). This, in turn, can
only be true if there are can never be any live references to any of the
classes defined by that loader, including C, either from their instances or
from code.
Class unloading is an optimization that is only significant for applications
that load large numbers of classes and that stop using most of those classes
after some time. A prime example of such an application is a web browser,
but there are others. A characteristic of such applications is that they manage
classes through explicit use of class loaders. As a result, the policy outlined
above works well for them.
Strictly speaking, it is not essential that the issue of class unloading be
discussed by this specification, as class unloading is merely an optimization.
However, the issue is very subtle, and so it is mentioned here by way of
clarification.
...
I can not understand the above very clearly:
now I guess that the Only way to unload MyHelper is to destroy its
classloader (for example, un-refrence all the refrence(s) to this
classloader, and/so force it to be GCed), am I right? thanks in advance!
Bo
Mar.01, 2001
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
