Cammarano Richard wrote:
> 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).
What happens if you run more than one web application in the same
servlet
container? If your connection pool classes are loaded from the system
class path,
then they get shared across applications as well -- creating security
risks as well
as more uncertainty in debugging because the connection pool is
available to ALL
classes within ALL your apps, whether they really need them or not. (It
seems
kinda like taping your PIN number on the back of your ATM card so you
can get to it
easily -- no problem unless you lose your wallet :-).
In some (most?) servlet containers, you can obviate the
cross-application exposure
if you put the connection pool classes under WEB-INF/classes or
WEB-INF/lib so that
they are loaded by the class loader for your application, but you are
depending
upon a container implementation detail (separate class loaders) that is
very
commonly implemented but isn't necessarily mandated.
I tend to design from a somewhat paranoid viewpoint -- my classes should
only have
access to what they need. Therefore, I tend not to use the Singleton
pattern
approach (static class methods) in most cases. It's personal
preference, but this
has kept me out of trouble on numerous occasions -- as well as forced me
to share
object access explicitly if I need it, which makes tracking down "where
did this
variable get changed" type problems much easier.
Craig McClanahan
>
> -----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
===========================================================================
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
