"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
