What Is a Connection Pool?
Opening a connection from scratch for every database request is costly: TCP handshake, authentication, session setup... Repeating these every time leads to latency and resource waste.
A Connection Pool solves this problem: a set number of database connections are opened in advance and held in a pool. Incoming requests borrow a connection from this pool, and return it when done. Connections are not repeatedly opened and closed; they are reused.
- ✓Faster response times — connection setup overhead is eliminated
- ✓Lower resource consumption — the database server carries no unnecessary load
- ✓More stable integration — the system doesn't crash on traffic spikes; it queues requests
How Does It Work in MuleSoft Database Connector?
MuleSoft's Database Connector uses a high-performance JDBC connection pool library called HikariCP under the hood. When you define a database connection (Database Config) in Anypoint Studio, you are actually configuring the parameters of this pool.
To access these parameters: follow the path Global Elements → Database Config → Advanced tab → Pooling Profile.
A flow requests a connection → a ready connection is provided from the pool (without TCP handshake) → the connection is returned when done → the next flow can use it. If the pool is full, new requests wait max-wait (5 s); if the timeout is exceeded, an error is thrown.
What Do the Parameters Mean?
Let's examine a typical configuration parameter by parameter:
| Parameter | Value | Description |
|---|---|---|
| Max pool size | 8 | The maximum number of connections that can be open at the same time. Once this limit is reached, new requests are queued. |
| Min pool size | 2 | The minimum number of connections always kept ready in the pool. Even at low traffic, 2 connections remain open. |
| Acquire increment | 2 | How many new connections are opened at a time when the pool is exhausted. Expands 2 at a time during sudden spikes. |
| Max wait | 5 s | The maximum wait time when no connection is available. If exceeded, the application throws an error. |
| Max idle time | 300 s | How long an unused connection is kept in the pool. Closed after 5 minutes, preventing resource waste. |
| Max statements | 50 | The number of prepared SQL statements cached. Prevents repeated compilation of the same queries. |
Problems Caused by Incorrect Configuration
When the connection pool is not configured correctly, you encounter two extreme scenarios:
When the pool is set too small:
- ✓At high traffic, requests waiting for a connection pile up, causing delays in flows
- ✓When the max wait time is exceeded, a timeout error is thrown — this can directly surface as a 500 error
- ✓If multiple flows share the same DB Config (e.g., insert + update), a contention condition arises
When the pool is set too large:
- ✓The database server unnecessarily carries too many connections, and the max_connections limit may be reached
- ✓DB access for other applications and services may be blocked
- ✓Memory and CPU resources are wasted
Connection Leak Risk
If a connection is taken and the process fails without properly returning it, the connection never goes back to the pool. Over time, the pool is exhausted and the application can no longer acquire new connections. This is called a connection leak.
MuleSoft largely manages this risk; the Database Connector automatically returns the connection when a transaction completes or an error is received. However, especially in scenarios with Try-Catch blocks and custom transaction management, this behavior needs to be carefully tested.
Recommended Approach
Every project has different needs, but the following approach is recommended as a general starting point:
- ✓Start with Min Pool Size: 2–5 and Max Pool Size: 10–20; fine-tune with load tests
- ✓Find out the max_connections value on the database side and keep the total of all applications below this limit
- ✓Define pool sizes separately for dev, test, and prod environments — manage them via properties files or Anypoint Runtime Manager
- ✓If multiple flows share the same Database Config (e.g., insert + update), factor this in when determining pool size
- ✓Monitor connection usage regularly with Kibana or Anypoint Monitoring
