get a connection every time the user requests the servlet (i.e. in the
doPost() ). Note thaty this will not generally create a connection as
normally one will be available in the pool and will be returned.
If you try to hold onto to a connection in your servlet by for instance
getting it in the int method and storing it in the servlet, then (aside from
concurrency poroblems!) the pool has less chance to act like a pool.
> -----Original Message-----
> From: Vikramjit Singh [SMTP:[EMAIL PROTECTED]]
> Sent: 25 June 2002 10:56
> To: [EMAIL PROTECTED]
> Subject: Re: which method is good for getting connection init() or
> doPost( )
>
> Sorry didnt put subject earlier,
>
> Seems like my question is not clear. I am using connection pooling, though
> not an application server, but one provided by oracle driver.
>
> There is a servlet which starts the connection pool when the server is
> started i.e. loaded on start up. I initialize the pool, and put it in the
> servers context by
>
> ServletContext context = getServletContext();
> context.setAttribute("CONNECTION_POOL", cpl);
>
> and then through the servlet i get the connection as.
>
> ServletContext context = getServletContext();
> OracleConnectionPool ocpl =
> (OracleConnectionPool)context.getAttribute("CONNECTION_POOL");
> OracleConnection tmpDbCon = (OracleConnection)ocpl.getConnection();
>
> So now i am saying which method is much better, related to design, number
> of
> clicks on the site.
> Putting the connection in the init() method and assigning it the
> connection
> permanently until the server is shutdown. Or getting a connection
> everytime
> a user requests the servlet doPost() and then release it.
>
> Regards,
> Vikramjit Singh,
> Systems Engineer,
> GTL Ltd.
> Ph. 7612929-1031
>
>
> -----Original Message-----
> From: It, Cockpit (CAP, Contractor) [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 24, 2002 11:05 PM
> To: [EMAIL PROTECTED]
> Subject:
>
>
> Hi Vikramjit,
>
> IMHO, both the practices are not much laudable.
> Yes its overhead to the resources to open and close the physical
> connection
> to the database for each request that arrives to your application.
> So, this is not better practice to use it.
> What your colleague is doing is also wrong. It might look right in one
> point
> that He/She is allotting a single connection to a servlet which will be
> used
> for all the request that particular servlet receives. But just think of a
> scenarios
> 1. where in more than one requests are coming to that servlet.......your
> servlet will keep the request in a web server's queue.
> Though your servlet is capable of handling more than one request at a
> time,
> it won't. Because it does not have a database connection in hand, which
> might be used by some other request arrived just before to this request.
>
> 2. Just think your application is having around 200 servlets which have to
> interact with the database. so when all your servlets have been accessed
> by
> the users at least for one time. Then your database will have 200
> connections open till your webserver/app server restarts which will
> destroy
> your servlets as well as connections. So Ideally you are locking the
> connections. Just think that one of your servlet is being accessed once in
> a
> week, that servlet will have a open connection till it's next request
> reaches.
>
> So the ideal way of handling connections would be ConnectionPooling. If
> you
> use App Server you can make use of it, because all the app server, that I
> know of, are providing facility for connection Pooling.
>
> If you are working with Web server just try to implement your own
> connection
> pooling concept, or just find one from the web, which are surely available
> on the net.
>
> But inefficient connection pool handling will also be a problem, so just
> take care of it.
>
> Basically in connection pool that has been implemented by your app server
> vendor would have a wrapper class to your connection object. so when you
> say
> connection.close() it basically tells the app server that you are done
> with
> using your connection, so it will collect your connection back to the
> pool.
> So using as minimum as 10 connections u can serve more than 100 users.
> Just
> search for Connection pool on google. you will get more about it.
> All the best.
>
> Yogaraj
>
> -----Original Message-----
> From: Vikramjit Singh [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 25, 2002 11:00 AM
> To: [EMAIL PROTECTED]
> Subject:
>
>
> Hi all,
>
> I have a doubt in which method is the proper way of getting connections. I
> am putting the connections in the server context, and getting the
> connections from the context by
>
> ServletContext context = getServletContext();
> OracleConnectionPool ocpl =
> (OracleConnectionPool)context.getAttribute("CONNECTION_POOL");
> OracleConnection tmpDbCon = (OracleConnection)ocpl.getConnection();
>
> First Method:
> I usually get the connection by the above method by putting it in the
> doPost
> method of the servlet.
>
> like public void doPost(HttpServletRequest req, HttpServletResponse res){
> ServletContext context = getServletContext();
> OracleConnectionPool ocpl =
> (OracleConnectionPool)context.getAttribute("CONNECTION_POOL");
> OracleConnection tmpDbCon =
> (OracleConnection)ocpl.getConnection();
> }
>
> My colleague says that this method has its overheads since each and
> everytime you fetch and release a connection. Which should be avoided.
>
> So she tried the second method
>
> Second Method:
>
> Instead of fetching the connection from doPost method, she put it in the
> init() method of the servlet like this
>
> public void init()
> {
> ServletContext context = getServletContext();
> OracleConnectionPool ocpl =
> (OracleConnectionPool)context.getAttribute("CONNECTION_POOL");
> OracleConnection tmpDbCon =
> (OracleConnection)ocpl.getConnection();
>
> }
>
> Now the servlet will always have a connection. This connection shall be
> released only when the destroy() method of the servlet is called. She says
> this is better, since you dont everytime have to get and release the
> connection. You have assigned one connection to it. If many users access
> this servlet, then the service method shall handle it.
>
> Could some java gurus throw some light on this.
>
> Regards,
> Vikramjit Singh,
> Systems Engineer,
> GTL Ltd.
> Ph. 7612929-1031
>
> ==========================================================================
> =
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST".
> For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST
> DIGEST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://archives.java.sun.com/jsp-interest.html
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.jsp
> http://www.jguru.com/faq/index.jsp
> http://www.jspinsider.com
>
>
> "THIS E-MAIL MESSAGE ALONG WITH ANY ATTACHMENTS IS INTENDED ONLY FOR THE
> ADDRESSEE and may contain confidential and privileged information.
> If the reader of this message is not the intended recipient,
> you are notified that any dissemination, distribution or copy of this
> communication is strictly Prohibited.
> If you have received this message by error, please notify us
> immediately, return the original mail to the sender and delete the
> message from your system."
>
> ==========================================================================
> =
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST".
> For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST
> DIGEST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://archives.java.sun.com/jsp-interest.html
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.jsp
> http://www.jguru.com/faq/index.jsp
> http://www.jspinsider.com
>
> ==========================================================================
> =
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST".
> For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST
> DIGEST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://archives.java.sun.com/jsp-interest.html
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.jsp
> http://www.jguru.com/faq/index.jsp
> http://www.jspinsider.com
--
It is the strict policy of Truworths that its e-mail facility and all
e-mail communications emanating therefrom, should be utilised for
business purposes only and should conform to high professional and
business standards. Truworths has stipulated certain regulations in
terms whereof strict guidelines relating to the use and content of
e-mail communications are laid down. The use of the Truworths e-mail
facility is not permitted for the distribution of chain letters or
offensive mail of any nature whatsoever. Truworths hereby distances
itself from and accepts no liability in respect of the unauthorised
use of its e-mail facility or the sending of e-mail communications
for other than strictly business purposes. Truworths furthermore
disclaims liability for any unauthorised instruction for which
permission was not granted. Truworths Limited accepts no liability
for any consequences arising from or as a result of reliance on this
message unless it is in respect of bona fide Truworths business for
which proper authorisation has been granted.
Any recipient of an unacceptable communication, a chain letter or
offensive material of any nature is requested to notify the Truworths
e-mail administrator ([EMAIL PROTECTED]) immediately in order that
appropriate action can be taken against the individual concerned.
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://archives.java.sun.com/jsp-interest.html
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.jsp
http://www.jguru.com/faq/index.jsp
http://www.jspinsider.com
