"Shun, Vadim" wrote:
> 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.
>
If your servlet container works correctly, it will always do the following in the
case of a reload request:
* Call destroy() on all currently active servlets.
* Reload the servlet classes as necessary
* Call init() on all load-on-startup servlets immediately,
or as they are requested otherwise.
Therefore, as long as you close the DB connection pools only in the destroy()
method, *and* you remove them from the context attributes at that time, you
shouldn't need an if statement in the init() method, which will always open the
connection pool and put it in.
>
> 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.
>
If your controller servlet (and the associated action classes) is the only place
you need the database connections, it is quite reasonable to use an instance
variable (with access methods) as you describe below.
>
> 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.
I agree -- this kind of dependency shouldn't cause you any problem.
>
> 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.
>
If you want to keep the controller servlet "pure", one way would be to keep all the
init/destroy stuff that initializes connection pools and other shared resources in
a separate servlet that you declare to be load-on-startup in the deployment
descriptor. You can also make sure user's cannot request this servlet to do
anything by providing no URL mapping to it -- it's only there to provide the
"lifecycle" support. As mentioned earlier, this should get cleaned up in the next
version of the servlet spec -- right now, we're just describing a way to work
around something that is missing.
>
> 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
