i am currently using a connection pool manager that is designed as a
singleton where I call ConnectionManager.getInstance() to return the
single pool instance. At first I was storing the connection manager in
the servlet context until my coworker pointed out that I didn't need to
store it at all. The singleton pattern guarantees the single pool
instance which can always be retrieved by
ConnectionManager.getInstance() no matter where you are in the
application (assuming you have imported the class in the JSP or
servlet).
-----Original Message-----
From: Craig.McClanahan
Sent: Friday, April 07, 2000 12:41 PM
To: JSP-INTEREST
Subject: Re: Model 2, where to store and access the Database
ConnectionPool
"Steven W. Rock" wrote:
> Hi All,
>
> Thanks for your thoughtful and enlightening threads of discussion on
the
> Model 2 architecture. I have been building a web site using Servlets,
beans,
> java classes and JSP based on this model. The one question I have
which
> seems to be missing from these discussions is where do I store the
> Connection Pool? My current thoughts are to initialize the connection
pool
> in the controller servlet init() function, create the Pool as a
Singleton,
> then any java class at the persistence level that needs a connection
just to
> call ConnectionPool.getInstance(). Is this what most people are
doing? The
> other option I suppose is to pass a connection through the Java Bean
Action
> class, down through the persistence java classes.
>
One option to consider is storing the connection pool as a servlet
context
attribute. Go ahead and create it in the init() method of your
controller servlet,
then execute:
ConnectionPool pool = ...;
getServletContext().setAttribute("pool", pool);
Now, if you've read my suggestions on the method signature of the
perform method in
action classes, you will note that I pass the servlet itself as an
argument:
public interface Action {
public void perform(HttpServlet servlet,
HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException;
}
One of the main reasons I do this is so that action classes have access
to the
resources of the servlet context. In particular, from within the
perform() method
of an action class, I can call:
ConnectionPool pool = (ConnectionPool)
servlet.getServletContext().getAttribute("pool");
Connection conn = pool.getConnection();
and pass the connection on to business logic beans that need it.
>
> In a similar vein, how do people handle logging. I wish to have one
logger
> class accessible by all classes in my application. This includes the
> Servlets, beans and regular java classes.
>
I use the same technique for other application-wide shared resources as
I described
for connection pools above -- store them in the servlet context
attributes. As an
added bonus, I can even refer to these resources in a JSP page:
<jsp:useBean id="logger" class="com.mycompany.mypackage.MyLogger"
scope="application"/>
or in an action class:
MyLogger logger = (MyLogger)
servlet.getServletContext().getAttribute("logger");
> I've programmed with a proprietary Application Server Web Objects,
that had
> one Application class that was accusable by all other classes in the
> application. Here I stored the logging, and any other global
services. How
> would I handle this with Servlets, JSP, bean Model 2 architecture.
>
That's pretty much what servlet context attributes are for.
>
> Thanks for your time in this matter.
>
> -Steven Rock
> hitmusic.com - choose and watch music videos of today's top hits.
>
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
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
===========================================================================
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
