Connection Pooling Concept of Java

Before we get into the concept of Connection Pooling first we need to understand what connection pooling is ?
And why do we need it?

Whenever we want our java application should talk to database we write some JDBC code in our java programe when we say JDBC, some class.forName(.....), and DriverManager.getConnection(.....) kind of statements come in your mind...
Ofcourse we need Connection obj in order to make our java application talking with Database.

If we simply write JDBC code in java application that means we are dealing with direct Connection obj from database.In case of dealing with this approach programmers need to create Connection object they need to maintain it during the execution of programe and they also need to take the responsibility to close the conn obj at the end.Moreover once this con obj is closed that can not be reused again.Suppose 100 clients are interested to communicate with database 100 conn obj will be created, managed and closed.
Somehow we find this way of communication with DB  is not at par so we need alternate of this approach and then Connection pooling concept came into the picture.Main purpose of connection pooling is to reuse the conn obj.

Client needs Conn obj from conn pool but directly client can't access this conn obj it has to undergo with DataSource obj.this DataSource obj acts like a mediator b/w client app and conn pool.
It is kept into registry area for more visibility and better performance.
First client makes a request to get DataSource obj from registry ...
on this DataSource obj it calls getConnection() method.
As soon as this method is being called DataSource obj occupies one conn obj from conn pool and the proxy of that conn obj is given to client in order to perform certain persistance operation.
After performing operation when client says con.close() then Closing event arrises and then immediately DS obj   
closes the proxy conn obj and orignal conn obj returns back to conn pool.

This returning obj is still alive i.e it can be used to provide the service to another client.
That is How Connection Pooling works internally..........

Connection Pooling - what is it and why do we need it?

It's a technique to allow multiple clinets to make use of a cached set of shared and reusable connection objects providing access to a database. Connection Pooling feature is supported only on J2SDK 1.4 and later releases.

Opening/Closing database connections is an expensive process and hence connection pools improve the performance of execution of commands on a database for which we maintain connection objects in the pool. It facilitates reuse of the same connection object to serve a number of client requests. Every time a client request is received, the pool is searched for an available connection object and it's highly likely that it gets a free connection object. Otherwise, either the incoming requests are queued or a new connection object is created and added to the pool (depending upon how many connections are already there in the pool and how many the particular implementation and configuration can support). As soon as a request finishes using a connection object, the object is given back to the pool from where it's assigned to one of the queued requests (based on what scheduling algorithm the particular connection pool implementation follows for serving queued requests). Since most of the requests are served using existing connection objects only so the connection pooling approach brings down the average time required for the users to wait for establishing the connection to the database.

How is it used?

It's normally used in a web-based enterprise application where the application server handles the responsibilities of creating connection objects, adding them to the pool, assigning them to the incoming requests, taking the used connection objects back, returning them back to the pool, etc. When a dynamic web page of the web-based application explicitily creates a connection (using JDBC 2.0 pooling manager interfaces and calling getConnection() method on a PooledConnection object ... I'll discuss both the JDBC 1.0 and JDBC 2.0 approaches in a separate article) to the database and closes it after use then the application server internally gives a connection object from the pool itself on the execution of the statement which tries to create a connection (in this case it's called logical connection) and on execution of the statement which tries to close the connection, the application server simply returns the connection back to pool. Remember you can still use JDBC 1.0 / JDBC 2.0 APIs to obtain physical connections. This of course is used very rarely - probably in the cases where connection to that particular database is needed once in a while and maintaining a pool of connection is not really needed.

How many connections the Pool can handle? Who creates/releases them?

These days it's pretty configurable - the maximum connections, the minimum connections, the maximum number of idle connections, etc. these all parameters can be configured by the server administrator. On start up the server creates a fixed number (the configured minimum) of connection objects and adds them to the pool. Once all of these connection objects are exhausted by serving those many clinet requests then any extra request causes a new connection object to be created, added to the pool, and then to be assigned to server that extra request. This continues till the number of connection objects doesn't reach the configured maximum number of connection objects in the pool. The server keep on checking the number of idle connection objects as well and if it finds that there are more number of idle connection objects than the configured value of that parameter then the server simply closes the extra number of idle connections, which are subsequently garbage collected.

Traditional Connection Pooling vs Managed Connection Pooling

Connection Pooling is an open concept and its certainly not limited to the connection pooling we normally notice in the enterprise application i.e., the one managed by the Application Servers. Any application can use this concept and can manage it the way it wants. Connection Pooling simply means creating, managing, and maintaining connection objects in advance. A traditional application can do it manually, but as we can easily observe that as the scalability and reach of the application grows, it becomes more and more difficult to manage connections without having a defined and robust connection pooling mechanism. Otherwise it'll be extremely difficult to ensure the maintainability and availability of the connections and in turn the application.