>The Tomcat thread pool is finite; we'll call the maxThread value T.
Likewise, the db connection pool is finite, and we'll call its size D. The
client makes some number of requests that are not committed, which we'll
label R. Anytime R > T + D, you're stuck.
Yes - that's my understanding of t
>all of the Tomcat threads are waiting for db connections to become available
So that implies that Tomcat only supports a max of 3 threads...
I uncommented:
in Tomcat's server.xml. But I still see the problem when I cap my db
connection pool at 3.
I would think that I should be able to in
>It's the top frames that are critical, of course, since they show where the
thread is stuck.
That stack trace is not from when the thread is hung - I put a bp on the
entry point to my code so that I could see what code an incoming request
must go thru before being passed to my code - my theory b
You're right, maybe I put this in the wrong forum. Below is a stack trace of
a request when it first enters my code on a successful request. In the error
case, my code is not being invoked.
I believe that all of the code below (except the top 4 call frames) are
coyote and catalina code. I thought
Tomcat does not return any error - any requests after I have exhausted the
pool,, are sitting in a wait state waiting for a DB connection to be freed.
No DB connections will be freed because the requests from the client that
are trying to perform commits (thereby freeing a DB connection) are not
b
I am deploying my web app war thru tomcat6.0 on Windows 2003 - I am not
changing any tomcat configuration files directly (or indirectly, afaik).
My app is using Hibernate for DB access and I have added c3p0 to handle DB
connection pooling to Hibernate.
I am seeing some strange results, that lead
