Re: very much a newbie design issue...

[Srinivasan S (Systems Engineering Group)]

So, instead of making my wait forever i shall wait for few seconds and
then stil no connection available can i close the client, i am not getting
u craig stil pls explain.  I havent get a clear answer for what will
happen for the 31st client who is accessing the servlet when that can
handle a pool of around 30 connections.  How long will he wait if no
threading is used?? pls consider a real time stuff, that html he is filing
out shall consists of around 30 html form he will fill it up all and still
if he didnt get a connection what will happen to him will his database
connection will be close and he need to retype them all, what will
happen?? pls take sometime to explain me abt this one.  Another point is
that does ConnectionPool is a in-built thread safe one??

srini

On Fri, 20 Aug 1999, Craig R. McClanahan wrote:

> "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
>

___________________________________________________________________________
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