Thanks Graig and Hans,
it comes to my mind that if this is the situation, storing global resources
in ServletContext is not a good idea at all under some circumstances.
At least, in case with my database connection broker this is what happens:
DbBroker is initialized in servlet init () method and put into servlet
context.
It is also closed on servlet destroy, closing the connections.
What happens when the servlet is reloaded (which happens frequently during
the development and sometimes even after production) - after reloading the
servlet since DbConnectionBroker is still in servletContext, it tries to
access it, and its been closed ("connections, etc). Boom! Has to reload
Tomcat to make it clear and reload servletContext.
One can suggest to nullify attribute containing DbConnectionBroker in
servletContext in servlet destroy"() function. But what is the point of it
anyway then to keep it in servletContext.
I am just about now to move my connectionBroker into servlet itself as a
class member.
The only thing I can add is that I thought over the weekend that it would be
nice for the future spec to support a callback mechanism for servletContext.
There is one for HttpSession at least, so the concept of it is definitely
not new to servlet interface designers at Sun. It is nice to know that such
thing is already considered.
Regards,
Vadim Shun
NEW Corp
Dulles, VA
-----Original Message-----
From: Craig McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 21, 2000 3:33 PM
Subject: Re: Cleaning global resources stored in ServletContext
"Shun, Vadim" wrote:
> Hi,
>
> I am storing some resources used on global level, such as database
> connection broker, in ServletContext.
> I am not sure however how to destroy them.
>
> The idea is that if this is the first time call, Controller Servlet init
> function initializes global resources and puts them in servlet context, so
> that all subsequent init functions reuse those resources. However I have a
> problem on how to destroying these global resources.
>
> Currently, my ActionServlet code has:
>
> public void destroy ()
> {
> // !!! actually should not do it here, should put in
servlet
> context destroy
> DbConnectionBroker dbConnBroker = (DbConnectionBroker )
> getServletContext().getAttribute ("dbConnBroker");
> if ( dbConnBroker != null )
> dbConnBroker.destroy (); // destroy connection pool
> super.destroy();
> }
>
> Servlet initialization funciton has the following fragment of code:
> // !!!init DB pool, put it in servlet context
> DbConnectionBroker dbConnBroker = (DbConnectionBroker )
> getServletContext().getAttribute ("dbConnBroker");
> if ( dbConnBroker == null ) {
> // create one here
> dbConnBroker = new
> DbConnectionBroker(dbDriver,dbServer,dbLogin,dbPassword,
> minConns,maxConns,logFile, maxConnTime);
>
> getServletContext().setAttribute ("dbConnBroker",
> dbConnBroker);
> }
>
> The problem is that from looking at this code I can see that every time
> servlet is destroyed, it will unload global resources from servlet
context,
> thus rendering the whole servletContext approach irrelevant (and dangerous
I
> would say if there are other servlets reusing those resources). Of course,
> every servlet instance during init will have to recreate it again.
>
> I cannot avoid thinking of C++ where templates allowed smart reference
> counting of classes, thus I would be able to see if global resources are
> still in use (like auto_ptr STL template class and similar). However there
> must be some easier approach in Java for this particular problem (maybe
some
> API call for servletcontext).
>
With the servlet 2.2 API, this is about the best you can do. Under most
servlet
containers, your controller servlet will not get unloaded (and therefore
destroy()
will not get called) until you shut down the server, so the resources you
make
available -- a connection pool in your case -- will stay available
throughout the
life of your application.
With the next version of the servlet spec, a better method to deal with
application events (like "startup" and "shutdown") is being looked at.
>
> Vadim Shun
> NEW Corp
> Dulles, VA
>
Craig McClanahan
>>
Context life-cycle support is one of the areas listed for analysis in
the specification work for JSP 1.2 (JSR 053). In JSP 1.0/1.1, the approach
you use (releasing context resources in the destroy() method of a servlet)
is
the best way to do it.
Hans
--
Hans Bergsten [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
===========================================================================
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
