David Chisholm wrote:
> Would the technique for preventing singleton objects from being garbage
> collected (as described in Doug Leah's Concurrent Programming in Java, I
> think) also prevent servlets from being unloaded? Basically, the technique
> calls from creating a thread that contains a reference to the singleton.
> The thread doesn't do anything, but because the VM maintains a reference to
> this thread, the thread cannot be gc'd and thus neither can the singleton.
>
The issue with servlets isn't really the same one. The "garbage collection"
problem on singletons happens because there is no live reference to them. With
servlets, unloading is a deliberate action that the server is explicitly allowed
to take, if it wants to. The servlet container might choose to unload a servlet
that hasn't been used for a long time, in order to make room (in memory) for a
newly requested one that has never been loaded yet.
>
> So, if a servlet is used in place of the singleton, can a servlet container
> unload the servlet even though a reference to that servlet still exists? I
> would think 'yes, it can', and it would cause unpredictable results.
>
In the 2.1 and 2.2 servlet APIs, there is no longer any legal way for an
application-level object (servlet or JavaBean) to acquire a reference to another
servlet instance. Therefore, the server can guarantee that there are no
dangling references to the servlet instance when it is unloaded, as long as it
manages its own references correctly.
>
> Just curious if anyone else had considered this and knows for certain, or
> has opinions on, what would happen.
> David
>
Craig
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
