If your purpose is to make sure that you don't ever wait for a significant
amount of time to get a connection, I'd just set your max pool size to the
number of threads you have set up in whatever container you're running in,
and then call it good.
If you want to set the number of connections to anything less than the
number of threads, then you could try something along the lines of:
1) Add instrumentation to your app and post-process the logs -- maybe Spring
logs something when it gets a connection.
2) I've seen the thread view in JProfiler 4, and it looked interesting. You
could find a method high up in your app's stack that requires a connection,
and then look at how often it's called over a certain period of time, and
how long each invocation takes.
3) If your app is CPU-intensive, consider changing your app to only get a
JDBC connection when it needs to talk to the db, and then put it back in the
pool while it's performing some kind of computation on the results. You'd
have to deal with ACID your own way if you want to make updates based on the
Given any one of the prior approaches, you could develop some heuristics
that let you optimize for db connection usage. In my experience, it's
totally app-specific, though, so sorry I couldn't give you anything more
> This is correct. Remaining question: "I would like to trace how the number
> of connections evolve. I.e. when are connections allocated, used,
> released, .... How can this be done (log file, JMX, ...) ?".
View this message in context: http://www.nabble.com/How-to-check-the-usage-of-Connections-in-a-Pool---tp23157254p23492408.html
Sent from the c3p0 - users mailing list archive at Nabble.com.