"Shun, Vadim" wrote:
> 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.
The way I do this now is to have a particular servlet (the controller servlet in a
"model 2" approach) do the following:
* In the init() method, create the DB connection broker and
store it in the servlet context.
* In the destroy() method, remove it from the servlet context
and close the connections.
That way, when you reload the context (because of auto-reload during development,
for example), the following things happen:
* destroy() gets called, so I close down the connections
gracefully and remove them from the context.
* the context gets reloaded.
* init() gets called immediately (if you define the servlet
to load on startup) or on the first request, and the
connection pool gets recreated.
>
> I am just about now to move my connectionBroker into servlet itself as a
> class member.
This works fine as long as you don't need access to it from other servlets or JSP
pages in the same application. That is the reason for storing it in the context
attributes in the first place.
>
> 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.
>
This whole area is definitely on the list of things being looked at in the next
servlet spec revision (JSR-053 in the Java Community Process).
>
> Regards,
>
> Vadim Shun
> NEW Corp
> Dulles, VA
>
Craig McClanahan
===========================================================================
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
