ped schrieb am 10.12.2008 um 10:33:23 (-0800): > > 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 the problem. But as I change D (my db > connection pool size) and R, Tomcat's maxThread value (T) seems to be > very small (1 or 2). That surprised me, and led me to think something > else was going on here.
Tomcat's maxThread is what you configure it to be. Quoting from your original post: | my client (written in GWT) executes a loop as follows: | 1 - remote call to web app to start a DB transaction (essentially | reserving a 3cp0 connection) Which will never go back to the pool. You think you're "reserving" it, but you'll never get back to it, so you're actually losing it. | 2 - on callback from 1, make a remote call to web app to perform a DB | query using the above transaction Another one that will never again be available for anybody, as you don't commit your work and don't give it back to the pool. | 3 - on callback from 2, make a remote call to the web app to commit | the db transaction (freeing the c3p0 connection) And another one, which there isn't any point in committing, as no work has been done in it. You have to close your connection each and every time to give it back to the pool. That's the idiomatics of the pool: Calling close() on a connection returns it to the pool. http://commons.apache.org/dbcp/apidocs/org/apache/commons/dbcp/PoolableConnection.html Michael Ludwig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
