Craig,
I think I get the point,
so every time on ActionServlet init() global resources need to be
reinitialized, not only the first time.
I had something along the lines (pseudocode):
if (servletContext.getAttribute ("DDbConnBroker) == null ) {
DbConnBroker dbConnBroker = new DbConnBroker ();
servletContext.setAttribute ("DbConnBroker",
dbConnBroker);
}
That did not work for servlet reloading as I described ("old" servlet
context is still present at reloading, but connection pool was already
closed at servlet destroy()).
You apparently are not using "if" statement. I.e. in servlet init() you
create dbConnectionBroker anyway. I think that should work fine for me too.
Regarding your suggestion to keep database broker in servlet context because
of extra accessibility to other servlets/JSPs. Maybe I did not get to this
point but I do not see where its needed. So far in no way I want my JSPs to
access the database, otherwise it will break the architecture and tiering.
Thus, it might be advantegous not to keep it there in order "not to tempt
junior developers" so to say. Maybe its needed for servlets but so far I
miss the point of it.
What I did yesterday was to keep database connection methods in
ActionServlet,
changed the Command (or Action) interface method Execute (or perform)
signature HttpServlet reference to ActionServlet in the following way:
public void Execute ( ActionServlet servlet, HttpServletRequest req,
HttpServletResponse res, String targetPageUrl ) throws IOException,
ServletException;
ActionServlet has 2 extra methods: getConnection and releaseConnection,
encapsulating connection options. These methods are accessible to
Command/Action implementors since its their responsibility to do JDBC calls.
The approach is not without drawbacks. All Command/Action implementation
classes have a new dependency on ActionServlet. I see no big deal in it
however since ActionServlet class is a stable class and thus it is a stable
and also non-circular dependency.
Bigger problem for me now is that ActionServlet is now mixing both
functionalities of controller and database connection management, i.e. it
has a little of Mediator and a little of Facade and I do not like such a
mixture of responsibilities. Your approach of keeping connection management
in servlet context does not have this problem. But as we discussed from the
point of view of classic object ownership your approach seem to be murkier.
Vadim Shun
NEW Corp
Dulles, VA
-----Original Message-----
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 24, 2000 11:41 AM
Subject: Re: Cleaning global resources stored in ServletContext
"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
