If you are using the Executor frameweork correctly, then you shouldn't be using that many database connections.
First, The executor executes the tasks on a
Thread pool. The size of the Thread pool is fixed (or can be limited). So, once you have created a ThreadPool. So, by definition, your ThreadPool will limit how many tasks will execute concurrently. If you are creating a Thread Pool for every hit, then you are making a big mistake.
You should have a single thread pool executor that executes all tasks from all hit on the application. You can tune the thread pool to be as large as the hardware can handle. However, don't keep instantiating and destroying thread pool. Thread are costly things, and since Thread Pools encapsulate a bunch of threads, Thread Pools are even costlier
Second, you should use a connection pool. Each task shouldn't open and close it's own connection. Instead you should have a single connection pool, and each task should borrow a connection from the connection pool, and return it back. Opening a a connection is a costly operation. A connection pool ensures that connections don;t open and close every time. Generally, speaking, your database can handle a lot more connections when you use a connection pool in the application. This is because it doesn't have to take the overhead of establishing connections
If you do what to run some queries in sequence, your simplest solution is to just have one task that execute all those queries in sequence. You might want to look at Spring batch, that allows you to sequence steps, and some steps can be run in parallel. However, Spring Batch may be overkill for you.
1
