In version 3.2 of Business Components for Java, connection pooling is the new default behavior. Instead of one JDBC connection being created for each application module instance, and being destroyed when the instance disconnects, application module instances can now reuse a pool of connections.
Opening a connection to a database is a time-consuming process that can sometimes take longer than getting the data itself. The advantage of connection pooling is that clients can have faster response times, because they are saved the time of creating the database connection. Instead, they can reuse a connection in an application module instance that already exists.
There is one connection pool for each JDBC connection URL, which includes the username and password. Here is a sample connection URL:
jdbc:oracle:thin:scott/tiger@myhost:1521:ORCL
For example, if you have three separate databases (one each of Oracle 8i, Oracle Lite, and a foreign database), the following connection types would have separate connection pools:
Oracle 8i with username jsm and password tiger
Oracle 8i with username scott and password tiger
Oracle Lite with username scott and password tiger
Foreign database with username pam and password tiger
As a result, connection pooling is most useful when many people log in to the same database using the same username and password.
The framework provides a connection pool manager to manage the pool. When a database connection is needed by a top-level application module instance, the following sequence of events occurs:
The application module instance asks the connection pool manager for a connection, as specified in the JDBC connection URL.
The connection pool manager looks for an available connection in the pool. If there isn't one, it creates one, up to the maximum allowable connections. If it can't create a connection, it waits for one (up to the timeout value).
When the application module instance disconnects, the connection goes back to the pool.
There is one connection pool manager for each business logic tier's Java VM. Connections remain in the pool until the Java VM stops running. The default maximum number of connections is a very large number, so it is essentially the number of connections supported by your database driver.
In addition to using the default behavior, you have these options:
You can set the maximum and initial number of connections in a pool.
You can disable connection pooling.
You can set the wait for connection timeout.
You can create and use a custom connection pool manager.
Related topics
Pooling Connections
Enabling and
Disabling Connection Pooling
Setting the Maximum Number
of Pool Connections
Setting the
Initial Number of Pool Connections
Setting the
Connection Pool Wait Timeout
Using a Custom Connection
Pool Manager