How to works connection pooling in Java and JDBC?

Connection pooling has become the standard for middleware database drivers. The process of creating a connection, always an expensive, time-consuming operation, is multiplied in these environments where a large number of users are accessing the database in short, unconnected operations. Creating connections over and over in these environments is simply too expensive.
The transaction profile for Web applications, probably the most common application in use today, is that of a large number of users performing short, discrete database operations. These applications usually perform work centered around creating a web page that will be sent back to the user's browser. Transactions are generally short-lived, and user sessions are often limited in time.
A connection pool operates by performing the work of creating connections ahead of time, In the case of a JDBC connection pool, a pool of Connection objects is created at the time the application server (or some other server) starts. These objects are then managed by a pool manager that disperses connections as they are requested by clients and returns them to the pool when it determines the client is finished with the Connection object. A great deal of housekeeping is involved in managing these connections.
When the connection pool server starts, it creates a predetermined number of Connection objects. A client application would then perform a JNDI lookup to retrieve a reference to a DataSource object that implements the ConnectionPoolDataSource interface. The client application would not need make any special provisions to use the pooled data source; the code would be no different from code written for a nonpooled DataSource.
When the client application requests a connetion from the ConnetionPoolDataSource, the data source implementation would retrieve a physical connection to the client application. the ConnectionPoolDataSource would return a Connection object that implemented the PooledConnection interface.
The PooledConnection interface dictates the use of event listeners. These event listeners allow the connection pool manager to capture important connection events, such as attempts by the client application to close the connection. When the driver traps a close-connection event, it intercedes and performs a pseudo-close operation that merely takes the Connection object, returns it to the pool of available connection, and performs any housekeeping that is necessary.
The operation of the connection pool should be completely transparent to the client application. The triggering of connection events, the manipulation of the object pool, and the creation and destruction of physical connections are all managed by the pool manager. The activities of the connection pool are, however, configurable by the application developer or the application deployer