David Marvin explains the difference between Connection Pooling and Connection Concentrator as follows:
Connection pooling is the methodology to place a connection for later re-use after an application has disconnected (no longer requires the connection). The next application which issues the “Please connect to database xxxxx” request would be given a connection in the connection pool matching the requested database. If none exist in the pool, generate a new connection. This saves the overhead of connection tear down/connection establishment. The application itself is unaware of what is going on under the covers. Typically, Application Server products (such as WebSphere) provide the connection pooling infrastructure. A DB2 Connect Server also provides Connection Pooling of backend connections to zDB2.
DB2 UDB/Connect connection concentration (CC), on the other hand, is a capability of these products to multiplex X application connections onto Y db2 agents where X > Y. db2 agents are the DB2 processes that serve an application connection. The use of the CC within a DB2 Linux Unix and Windows (LUW) server allows reduced resource usage at the DB2 Server (fewer db2agents required). The use of the CC with DB2 Connect provides the following:
- If configured appropriately, it reduces resource usage at the DB2 Connect server as well as at the DB2 z/OS server (fewer db2agents at the Db2 Connect Server which implies fewer connections to DB2 z/OS). Configuring for reduced resource consumption is an option and is not necessary to leverage other capabilities the Connection Concentrator in DB2 Connect provides … read on
- Leverages a DB2 z/OS Data sharing / sysplex group. DB2 z/OS provides a DB2 Connect server with a weighted list of members in the sysplex refreshed after each transaction completes. New transactions / connection requests initiated by the application will be routed to the “least busy” member in order to provide load balancing in the sysplex.
- Failover capability in the event a DB2 z/OS member fails. The particular in-flight transactions to this member will be rolled back but the application will be rerouted to another member and can retry the failed transaction (or any other logic the application wishes to implement).
The use of the CC adds overhead and is not “free”. In particular, if X is much greater than Y , there will be contention by applications to get a much smaller set of db2agents for processing. Additionally, even if X=Y+1 (this is the means to activate CC when the application environment only wants sysplex load balancing and fail-over exploitation), in order to be able to utilize any connection in the sysplex for the “next transaction” induces additional overhead. Application owners will need to decide what they wish to accomplish using this technology and then weigh this requirement against the observed overhead added to their application environment.
Please note that the DB2 Driver for JDBC and SQLJ type 4 driver also contains the ability for CC, sysplex load balancing exploitation.