Each access of a servelet does not create a new servlet, but rather spawns a new thread that access the existing instance, so in order to allocate only one connection to a servlet, you would then need to syncronize all accesses to the connection - this will incur a significant performance penalty.
In general always get a new connection from the pool in the actual method (e.g. doPost() ) that needs it (as a local variable too, to avoid concurrency issues), and return it at the end of that method. Assume that there is always a connection available in the pool (as this is the case 99.99% of the time) and hence the cost of obtaining a connection from the pool is negligible. Tom summarise it is much more effecient in terms of performace to fetch the connection everytime you need it as no syncronization is needed, and there is no difference in overhead as usually an existing connection is pulled from the pool. Cheers Adrian > -----Original Message----- > From: Vikramjit Singh [SMTP:[EMAIL PROTECTED]] > Sent: 25 June 2002 12:36 > To: [EMAIL PROTECTED] > Subject: Re: which method is good for getting connection init() or > doPost( ) > > Yeah, > thats what i do. Thats some nice explanation that the pool has less chance > to act as pool. But if one servlet is accessed very often. Isnt it better > to > give it a connection, rather than everytime fetching a connection from the > pool, and then returning it back to the pool. Which is more efficient in > terms of performance or overhead. > > Regards, > Vikram. > > > -----Original Message----- > From: Adrian Janssen [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 25, 2002 2:24 AM > To: [EMAIL PROTECTED] > Subject: Re: which method is good for getting connection init() or > doPost( ) > > > 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. > > > 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 > > ========================================================================== > = > 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
