JDBC

Pooling JDBC connections to the database in WebLogic Server improves application performance. The connection pool eliminates the need for creating new database connection for each application. The JDBC Connection Pool provides ready-to-use connections to your database.
The number of connections to the database can be dynamically resized when using a connection pool. But trying to increase the number of JDBC connections during a peak load situation can worsen the situation, because database connection creation is expensive.
Connection pool also increases the performance by caching prepared statements and callable statements for reuse. Reusing prepared statements and callable statements reduces CPU usage on the database server.
Avoid draining processing power on the WebLogic Server machine by separating other applications on a separate machine or hardware; use a dedicated machine for databases.
Tips
1. If possible, size database connection pools so that they never increase the number of connections: set Initial Capacity equal to Maximum Capacity.
2. Set the Maximum Capacity of the connection pool at least equal to the Execute Thread Count.
3. Configure Inactive Connection Timeout to specify how long (in seconds) a connection can be inactive before it is reclaimed to the pool.
4. The connection leak profiling option shows leaked connections from the connection pool. BEA recommends that you do not use this option in production; it uses extra resources and typically slows connection-pool operations.
5. Use Test Reserved Connections only if you can afford the overhead of testing connections as part of normal request processing.
6. Avoid using a production table for "Test Table Name", use a dummy table (ex. dual).
7. Use the statement cache to improve performance of prepared and callable statements.
8. Select the least-recently-used (LRU) algorithm for the cache; this removes rarely used statements from the cache.
9. Connection Creation Retry Frequency can be used to retry for establishing connections to the database, if database is not reachable when creating connection pool or starting WebLogic Server.
10. If database is restarted when WebLogic Server is running, Test Frequency can be increased from 0, so that all the connections are closed and reopened to re-establish valid physical connection. After all the connections are recreated changing it back to 0 will disable the testing.
11. When using DataSource objects for a connection pool, use the Honors Global Transaction option to create a TxDataSource.
12. The only time you should use a non-Tx DataSource is when you want to do some work on the database that you do not want to include in the current transaction.
13. When configuring a connection pool to use with WebLogic JMS JDBC Store, use non-XA database drivers.