Why to use connection pooling
When you use the DriverManager or DataSource method to get a database connection, each request for a new database connection can incur significant overhead. If you get new connections frequently, you will affect performance, which may occur in a WEB server environment. To emphasize why this happens, let's look at the underlying path to a typical database connection request.
- Java application calls
getconnection () .
- JDBC Vendor code (driver or
DataSource Implementation) requests a socket connection from the JVM. The
- JVM needs to check the security aspects of the underlying invocation. For example, applets are only allowed to communicate with the server that generated them.
- If allowed, the call needs to traverse the host network interface to the corporate LAN. A
- call may need to reach the Internet or WAN through a firewall. The
- Call eventually arrives at the destination subnet, where it may need to pass through another firewall. The
- call arrives at the database host. The
- Database server processes new connection requests. The
- license server may require a query to determine whether there is an appropriate license. The
- Database Initializes a new client connection, including all memory and operating system overhead. The
- return call is sent back to the JDBC client (where it must pass through all firewalls and routers). The
- JVM receives the return call, and then creates the appropriate
object.
- requested Java application received
connection object.
Obviously, asking for a new Connection object can lead to a lot of overhead and a lot of potential errors. In order to minimize overhead, why not reuse them after we have finished using the database connection, instead of removing them? The JDBC designer ConnectionPoolDataSource uses this popular design pattern when it is created, which allows you to create a database connection pool where connections can be reused, rather than deleted, when they are closed.
Why to use connection pooling