"Srinivasan S (Systems Engineering Group)" wrote:

> Exactly this is what i am thinking for, all the example in the books and
> articles are static meaning only 20 or 30 connections are created just
> imagine a html form consists of nearly 30 columns and the user fills those
> columns after he press the submit button being 31st client in the pool he
> will get an error, instead this client shall be made wait till a
> connection is free in this pool.  My question is that i am running a
> thread in my code which checks for any free connection and wait if not.
> Another method provides connection to the user, if i call the connection
> method from another code what will happen if no connection available.
> for example:
>

Connection pool strategies work best when you always give the connection back to
the pool *before* you return to the browser.  That way, a pool of 30 connections
can serve 30 *simultaneous* requests, but a much larger pool of active users
(depending on how often they are hitting your site).

Thus, a generic service() (or doGet() or doPost() ) method that needed to do
database work would look like this:
* Process the incoming request parameters
* Allocate a connection from the pool
* Do the processing work followed by
  a COMMIT or ROLLBACK (if your database
  uses transactions)
* Release the connection back to the pool
* Finish generating the HTML output

In this way, the connection used for a particular request is available to serve
somebody else while the user is looking at the output, instead of being stuck in
that user's session.

When you request a connection from the pool when there are none available, most
connection pools make your thread simply wait for one.  Some pool implementations
might offer the ability to set a timeout so that they won't wait "forever".  If
most of the requests are short (milliseconds to one or two seconds), you
shouldn't have to wait very long.  If you find yourself waiting a lot, that's a
sign that you need more connections in the pool to support the current user
population.

Craig McClanahan

___________________________________________________________________________
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

Reply via email to