By adhering to a small number of relatively simple connection pooling best practices your application can quickly and easily take effective advantage of connection pooling.
Software Object Pooling
Object pooling is effective for two simple reasons. Object pooling does require additional overhead for such tasks as managing the state of the object pool, issuing objects to the application and recycling used objects. In a
pooling scenario your application first creates an object pool that can both cache pooled objects and issue objects that are not in use back to the application. For example, pooled objects could be database connections, process threads, server sockets or any other kind of object that may be expensive to create from scratch. As your application first starts asking the pool for objects they will be newly created but when the application has finished with the object it is returned to the pool rather than destroyed. At this point the benefits of object pooling will be realized since, now as the application needs more objects, the pool will be able to issue recycled objects that have previously been returned by the application.
JDBC Connection Pooling
Java JDBC connection pooling is conceptually similar to any other form of object pooling. Database connections are often expensive to create because of the overhead of establishing a network connection and initializing a database connection session in the back end database. If your application runs within a J2EE environment and acquires JDBC connections from an application server defined data source then your application is probably already using connection pooling. Your J2EE application simply acquires JDBC connections from the data source, does some work on the connection then closes the connection. Your application’s use of connection pooling is transparent. Connection pool implementations are available from JDBC driver vendors and a number of other sources.
Connection Pooling – what is it and why do we need it?
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 explicitly creates a connection (using JDBC 2.0 pooling manager interfaces and calling getConnection() method on a Pooled Connection 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.
How many connections the Pool can handle? On start up the server creates a fixed number (the configured minimum) of connection objects and adds them to the pool. 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 it’s certainly not limited to the connection pooling we normally notice in the enterprise application i.e., the one managed by the Application Servers. Connection Pooling simply means creating, managing, and maintaining connection objects in advance.