How to find JDBC connection pool threads created in SpringBoot application?

Question

I have been the following properties in my Spring Boot 1.4 application talking to local MySQL using JDBC -

• spring.datasource.test-while-idle=true
• spring.datasource.test-on-borrow=true
• spring.datasource.validation-query=SELECT 1
• spring.datasource.initial-size=50
• spring.datasource.max-active=100
• spring.datasource.max-idle=50
• spring.datasource.min-idle=50
• spring.datasource.initial-size=50
• spring.datasource.tomcat.max-active=100
• spring.datasource.tomcat.max-idle=50
• spring.datasource.tomcat.min-idle=50
• spring.datasource.tomcat.initial-size=50

I know last four lines are repeats, but I have kept those to try out if any combination works. Spring Boot documentation says all datasource tomcat properties shall be under spring.datasource.tomcat.*. On the other hand, first three lines are working on SpringBoot 1.3 and 1.4. So, expectation was the connection pool parameters will work also.

After starting the application, I checked all of its threads in VisualVM. The count is ~20 which is much lesser than 50 which I have set. After firing say 1000 REST calls which talk to MySQL using Spring Data repositories, I see the thread count is increasing beyond 50. However, once the REST calls are over and after a little while, the thread count goes down to ~30. I see ~10 worker threads remain idle.

So, my query is, how will you detect JDBC connection pool threads in Spring Boot application thread pool?

Also, what's wrong in the property configuration? Why JDBC connection pool of expected thread count is not getting created?

Answer 1

A connection pool doesn't create threads (or: it might create 1 or 2 for housekeeping, but that is it). A connection pool creates (and tracks) JDBC connections to a database to hand out when your application asks for it. There is no need to have a thread per connection in the pool itself.

Most threads you see are either from Java itself (eg garbage collection, etc) plus the threads needed to handle the HTTP connections (which might increase under load and decrease when idle), and any other threads spun up by your application code.