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.
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.
Just curious if anyone else had considered this and knows for certain, or
has opinions on, what would happen.
David
> -----Original Message-----
> From: A mailing list about Java Server Pages specification and reference
> [mailto:[EMAIL PROTECTED]]On Behalf Of Craig R. McClanahan
> Sent: Thursday, November 18, 1999 10:38 AM
> To: [EMAIL PROTECTED]
> Subject: [Fwd: Question about Servlet lifetime]
>
>
> [Forwarded (with a couple of comments) for Daniel Lopez, who is
> apparantly having
> problems with his JSP-INTEREST subscription]
>
> Craig McClanahan
>
>
>
> Daniel Lopez wrote:
>
> > Hi,
> >
> > I'm dealing with this using the OneServlet approach. As I only have one
> > servlet, the dispatcher one, I can load the application-wide resources
> > during init() and clean them inside destroy(). If the servlet engine
> > decides to unload my servlet then resources are cleaned and this servlet
> > controls all my "applications" so there's no way my "applications" can
> > work with this servlet unloaded so it will be loaded again as soon as
> > anyone tries to access any operation inside an "application" so all the
> > resources will be loaded again. This could seem to cause too many
> > loads/unloads but I've configured my servlet engine to load this servlet
> > on start time and I've never seen the engine to unload it as it is using
> > it all the time(Note: I'm using JRun so this could be engine dependent).
>
> Yes it is engine dependent. For example, JSWDK and Tomcat
> (current version) do not
> unload servlets either, while Apache JServ will unload them if
> you turn on the "auto
> reload on repository changes" feature. You would need to check
> your JRun documentation,
> or ask their support folks.
>
> >
> > Regarding the portable way of specifying "application start" and
> > "application stop" events, thanks to using the OneServlet approach we do
> > the following:
> > .- Each "application" specifies a class that implements the interface
> > public interface HttpAppLifeCycle
> > {
> > // Method called when the "application" is started
> > public void onApplicationStart(ServletContext theContext)
> > throws HttpApplException;
> >
> > // Method called when the "application" is stopped
> > public void onApplicationStop(ServletContext theContext)
> > throws HttpApplException;
> >
> > // Method called when a request to the "application" is performed
> > public void onApplicationRequest( ServletContext theContext,
> > HttpServletRequest theRequest)
> > throws HttpApplException;
> > }
> >
> > and then the dispatcher servlet takes care of calling the appropriate
> > methods at the appropriate times. We've sophisticated things a bit more,
> > adding security, a management console, the possibility of
> > enabling/disabling "applications" etc.. but I hope you can get the point
> > with this brief explanation.
> >
> > Note: We define an "application" as a coherent set of operations that
> > share the same lifecycle and security settings and in our case we don't
> > use servlets to implement the operations, that's the reason why I used
> > the "" so nobody gets confused with the name: application.
> >
>
> In the servlet 2.2 spec the term "web application" is used,
> because there is a
> one-to-one correspondence between web applications and
> ServletContext. I think you'll
> find that your usage of it fits with this pretty well.
>
> >
> > I hope this helps, comments are also appreciated.
> > Dan
> > PD: Craig, would you mind forwarding the message to the JSP list,
> > please? I'm still waiting for a definitive answer from the list
> > administrators regarding my problem. Thanks.
> >
> > "Craig R. McClanahan" wrote:
> > >
> > > Jeffrey DeLeo wrote:
> > >
> > > > I'm currently using the following architecture to initialize
> > > > application-wide resource (such as database connection pools):
> > > >
> > > > Define a servlet that in:
> > > >
> > > > init() - creates resources, and stores them as attributes
> on the servlet
> > > > context
> > > >
> > > > destroy() - removes these attributes from the servlet
> context. As this is
> > > > the only reference to
> > > > them, they are then unavailable, and will eventually be
> garbage collected.
> > > >
> > > > Different JSP pages can then grab these resources as
> application-scope beans.
> > > >
> > > > Reading the Servlet specification, it says the Servlet
> container can unload
> > > > a servlet at any time - this means that my global resources
> will suddenly
> > > > become unavailable! Is this correct?
> > > >
> > >
> > > If you use the code described above, yes that is correct.
> > >
> > > >
> > > > How are other people dealing with the problems of
> > > > initialization/destruction of application-scope resources?
> > > >
> > >
> > > The servlet specification is currently missing a clean,
> portable, way to deal with
> > > "application start" and "application stop" events. IMHO this
> is a high priority
> > > for the next spec version.
> > >
> > > The alternative that has worked best for me is to use a
> servlet container that does
> > > *not* arbitrarily unload servlets -- such as the JSWDK or the
> current version of
> > > Jakarta Tomcat -- or does so when you turn on the
> "autoreload" feature, like Apache
> > > JServ. But that's not always an option. Another approach
> would be to call a
> > > special servlet at shutdown time that does the removals, and
> make sure it is never
> > > called at any "normal" time.
> > >
> > > Craig McClanahan
> > >
> > >
> ==================================================================
> =========
> > > 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
> >
> > --
> > -------------------------------------------
> > Daniel Lopez Janariz ([EMAIL PROTECTED])
> > Web Services
> > Computer Center
> > Balearic Islands University
> > -------------------------------------------
>
> ==================================================================
> =========
> 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
>
===========================================================================
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
