I believe most real-world ConnectionPool implementations get away with
their singleton-ness and supposedly garbage-collectable-ness by having a
background thread that keeps track of the static reference. This
background thread is responsible for items like monitoring stats,
reducing the pool time at idle times, detecting database restarts and
initiating re-connections, etc. Since this thread is still active with
a reference to the pool, the GC cannot collect it.
-=- D. J.
Sam Heisz wrote:
> On Fri, 7 Apr 2000, Sam Heisz wrote:
> sam>> What stops the instance from getting garbage collected? I read
> that
> sam>> starting version something-something-something, the garbage
> collector
> sam>> is more aggressive and will collect instances of objects that are
> only
> sam>> referred to by a member variable in the same class.
>
> Wes Biggs wrote:
> wes> Do you have a reference? That would break tons of code out there,
> wes> including parts of the JDK itself that utilize the singleton
> pattern.
>
> Java In Practise: Design Styles And Idioms For Effective Java
> by Phil Bishop , Nigel Warren
> ISBN 0201360659
>
> page 131:
>
> "JDK 1.1.x specification added the feature of class unloading...
> where the only reference to the Singleton object is maintained within
> the Singleton class itself, the garbage collector, in its enthusiasm to
> dispose of any unused trash, may assume that the Singleton is
> unreachable because no other object or class holds a current reference
> to it and could quite legally garbage collect the object and unload the
> class...'
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
