Thanks for the feedback.!!
-------------------------------------------------------------------------
James C. Bragg
Senior Software Consultant
Computer Associates International Inc
> -----Original Message-----
> From: Craig R. McClanahan [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, June 27, 2000 8:13 PM
> To: [EMAIL PROTECTED]
> Subject: Re: ConnectionPool Object stored in ServletContext
>
> "Srini Sathya." wrote:
>
> > i too seriously thinking of this approach, i remember craig has sometime
> > back recommended this approach to one of the questions (if we are not
> using
> > EJB), might be as usual he will shed some light to us in this query.
> Craig
> > comeon with ur usual tone of clear and clarity answers!!! [ It is not
> > intended to offend anyone in the list, my apologies if this is gonna to
> > offend anyone ].
>
> :-)
>
> The approach that James suggests (store a connection pool in the servlet
> context
> attributes) is the approach that I have used in my own applications. It
> makes
> the connection pool available to all of the servlets and JSP pages in my
> application (in JSP, you can reference it as an application-scope bean),
> and --
> just as importantly -- makes the connection pool *unavailable* to any
> other
> application running in the same server. Therefore, the other apps cannot
> scribble (either intentionally or unintentionally) on my database.
> Depending on
> how your servlet container is built, you do not necessarily get this
> protection
> if you use a singleton approach to implementing the pool.
>
> I tend to configure and create a connection pool in the init() method of a
> servlet, based on servlet initialization parameters. To make sure that
> the pool
> is available immediately, I also tell my servlet container to load this
> servlet
> immediately at startup time (for a container that implements the 2.2
> specification, you do this by adding a <load-on-startup> element to your
> servlet's description in the web.xml file). Finally, to clean things up
> when
> the server is shut down, I added code to the destroy() method of this same
> servlet to gracefully close all the connections.
>
> This last feature is the only (potential) gotcha that I have run into with
> this
> approach. What you really want to have happen is that your "database pool
> creator" servlet be loaded when the server is started, left in memory the
> entire
> time the server is running, and unloaded only when the server is shut
> down.
> However, the servlet spec gives your container the right to unload a
> servlet any
> time it feels like it -- which would cause the database connections to
> disappear
> in our scenario here.
>
> In practice, most of the servlet containers I'm familiar with do not in
> fact do
> this. If yours does, the best workaround is to do the following:
> * In the destroy() method, do not shut down the pool -- leave it running
> * Provide some other mechanism to close down the pool if you want to
> * In the init() method, check to see if the pool is already
> present in the servlet context attributes (because it was
> put there by a previous startup of this servlet.
>
> Other than that, storing the connection pool (or any other shared resource
> that
> is needed by more than one servlet and JSP page in your app) is a very
> useful
> technique.
>
> >
> > Regards
> > Srini
>
> Craig McClanahan
>
>
> >
> > -----Original Message-----
> > From: Bragg, James [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, June 27, 2000 5:03 PM
> > To: [EMAIL PROTECTED]
> > Subject: ConnectionPool Object stored in ServletContext
> >
> > I am planning on storing my ConnectionPool Object into the
> ServletContext so
> > that all of my Servlets will be able to use one connection-pool, instead
> of
> > creating a different pool for each servlet. A Connection-Pool will be
> > create and stored into the servlet context at server startup. Is there
> any
> > potential problem with this approach.
> >
> > thanks..
> >
> -------------------------------------------------------------------------
> > James C. Bragg
> > Senior Software Consultant
> > Computer Associates International Inc
> >
> >
> __________________________________________________________________________
> _
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > Resources: http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
> >
> >
> __________________________________________________________________________
> _
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > Resources: http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
> __________________________________________________________________________
> _
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
