"Srinivasan S (Systems Engineering Group)" wrote:
> 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
>
First thing ... if you follow the advice I gave (return connections to the pool before
returning from the servlet), it is the 31st *simultaneous request* that would have to
wait, not the 31st concurrent user of your application. There is a big difference.
>From the technical perspective, you could probably support a couple of hundred
concurrent users with 30 connections, because they are not all hitting the site at the
same time. While the users are reading the response pages, the connections are
available to serve other users.
Second thing ... the longest that this 31st request would ever have to wait for a
connection is equal to the longest amount of time that any database actions taken by
any of the database transactions you are doing. Most things will proably take less
than a second ... but let's assume you have one particular select that takes 10
seconds, because it has to process a lot of data to calculate the results you need.
In that case, the user who had to wait will perceive a delay of whatever he would
normally see (to do the action he requested) plus a maximum of ten extra seconds.
Note that you will experience this maximum delay only if *all* of the requests being
done right now are the long-running ones, and they all started very recently. In most
systems, the average delay will be *much* shorter than the maximum delay. (Dig out a
university-level Queueing Theory textbook for the mathematics behind this.)
Other than the extra time delay, nothing special happens -- to either the user or your
servlet code. The user just thinks it took a little longer than usual. Your servlet
doesn't "perceive" the time it spent waiting -- it just calls the allocate method of
the connection pool, and politely waits until a connection is available.
If the maximum delay is too long, there are a couple of things you can do about it:
* Increase the number of connections available, so that no one
has to wait for one -- but there's an upper limit here, based
on the capacity of your database system.
* Tune the long-running SELECT, by adding indexes or improving
the selection criteria, so that it doesn't take ten seconds any more.
* Change the application design to reduce the number of times
that the long-running SELECT needs to be requested.
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
