Skip navigation.
Downloads | Product Documentation | Support

Administration Console Online Help

# JDBC Connection Pool --> Configuration --> Connections

Tasks Related Topics Attributes

## Overview

In the JDBC Connection Pool—>Configuration—>Connections tab, you specify the number of connections in the connection pool and details for each connection in the connection pool.

A connection pool contains a group of JDBC connections that are created when the connection pool is registered, usually when starting up WebLogic Server. Your application borrows a connection from the connection pool, uses it, then returns it to the connection pool by closing it.

## Tasks

Creating and Configuring a JDBC Connection Pool

Deploying a JDBC Connection Pool to One or More Servers or Clusters

Cloning a JDBC Connection Pool

Monitoring Connections in a JDBC Connection Pool

## Related Topics

Increasing Performance with the Statement Cache

Automatically Recovering Leaked Connections

Initializing Database Connections with SQL Code

Connection Testing Options

JDBC

Programming WebLogic JDBC

Third-Party Driver Configuration and Performance Requirements in Programming WebLogic JTA

## Attributes

Table 113-1

Attribute Label | Description | Value Constraints
--- | --- | ---
Initial Capacity | The number of physical database connections to create when creating the connection pool. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `InitialCapacity` | Minimum: 0 Maximum: 2147483647 Default: 1 Dynamic: yes
Maximum Capacity | Maximum number of physical database connections that this connection pool can contain. Different JDBC Drivers and database servers may limit the number of possible physical connections. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `MaxCapacity` | Minimum: 1 Maximum: 2147483647 Default: 15 Dynamic: yes
Capacity Increment | Increment by which the connection pool capacity is expanded. When there are no more available physical connections to service requests, the connection pool will create this number of additional physical database connections and add them to the connection pool. The connection pool will ensure that it does not exceed the maximum number of physical connections as set by `MaxCapacity`. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `CapacityIncrement` | Minimum: 1 Maximum: 2147483647 Default: 1 Dynamic: yes
Statement Cache Type | The algorithm used to maintain the statement cache: LRU - After the `statementCacheSize` is met, the Least Recently Used statement is removed when a new statement is used. Fixed - The first `statementCacheSize` number of statements is stored and stay fixed in the cache. No new statements are cached unless the cache is manually cleared. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `StatementCacheType` | Default: LRU Valid values: LRU FIXED Dynamic: no
Statement Cache Size | The number of Prepared and Callable Statements stored in the cache for further use. WebLogic Server can reuse statements in the cache without reloading them, which can increase server performance. Setting the size of the statement cache to 0 turns it off. Each connection in the pool has its own cache of statements. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `StatementCacheSize` | Default: 10 Dynamic: yes

#### Advanced Attributes

Table 113-2

Attribute Label | Description | Value Constraints
--- | --- | ---
Login Delay | The number of seconds to delay before creating each physical database connection. This delay takes place both during initial pool creation and during the lifetime of the pool whenever a physical database connection is created. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `LoginDelaySeconds` | Units: seconds Minimum: 0 Maximum: 2147483647 Default: 0 Dynamic: no
Seconds to Trust an Idle Pool Connection | The number of seconds within the use of a pooled connection that WebLogic Server trusts that the connection is still viable and will skip connection testing. If an application requests a connection within the time specified since the connection was tested or successfully used and returned to the connection pool, WebLogic Server skips the connection test before delivering it to an application (if TestConnectionsOnReserve is enabled). WebLogic Server also skips the automatic refresh connection test if the connection was successfully used and returned to the connection pool within the time specified (if TestFrequencySeconds is specified). This attribute is a tuning feature that can improve application performance by minimizing the delay caused by database connection testing, especially during heavy traffic. However, it can reduce the effectiveness of connection testing, especially if the value is set too high. The appropriate value depends on your environment and the likelihood that a connection will become defunct. | Units: seconds Minimum: 0 Maximum: 2147483647 Default: 0 Dynamic: no
Remove Infected Connections Enabled | Applies only to physical database connections. When set to true, the physical connection is not returned to the connection pool after the application closes the logical connection. Instead, the physical connection is closed and recreated. Note: It is recommended that you set this flag to true as such connections are not managed by WebLogic Server. When set to false, if you close the logical connection, the physical connection is returned to the connection pool. If you use this setting, ensure that the database connection is suitable for reuse by other applications. This parameter is applicable only if the application gets a connection from the connection pool and then calls the `getVendorConnection()` method on that object. The `getVendorConnection()` method returns a vendor specific connection to the caller of the method which might leave the connection pool in an inconsistent state. As a result, WebLogic Server might remove it from the pool assuming it is an infected connection. Enabling this attribute will have an impact on performance as it will essentially disable the pooling of connections. This is because connections will be removed from the pool and replaced with new connections. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `RemoveInfectedConnectionsEnabled` | Default: true Valid values: true false Dynamic: no
Allow Shrinking | Indicates whether or not the pool can shrink back to its `InitialCapacity` when it is detected that connections created during increased traffic are not being used. When shrinking, the number of connections is reduced to the greater of either the initial capacity or the current number of connections in use. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `ShrinkingEnabled` | Default: true Valid values: true false Dynamic: yes
Shrink Frequency | Number of seconds to wait before shrinking a connection pool that has incrementally increased to meet demand. `ShrinkingEnabled` must be set to true for a connection pool to shrink. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `ShrinkFrequencySeconds` | Units: seconds Minimum: 0 Maximum: 2147483647 Default: 900 Dynamic: yes
Enable Connection Leak Profiling | Specifies that JDBC Connection leak profiling information is gathered. A Connection leak occurs when a connection from the pool is not closed explicitly by calling `close()` on that connection. When connection leak profiling is active, the connection pool will store the stack trace at the time the Connection object is allocated from the connection pool and given to the client. When a connection leak is detected (when the Connection object is garbage collected), this stack trace is reported. This option is required to view leaked connections from the connection pool (right-click the connection pool name and select View Leaked Connections). This feature uses extra resources and will likely slow down connection pool operations, so it is not recommended for production use. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `ConnLeakProfilingEnabled` | Default: false Dynamic: yes
Enable Connection Profiling | When selected, WebLogic Server stores the stack trace whenever a connection object is released back into the connection pool. If an exception is thrown during a subsequent operation on the connection related to global (XA) transactions, WebLogic Server reports this stack trace with the exception. You can use this feature to detect local transaction work left incomplete by application code, which can interfere with subsequent global (XA) transaction operations on the JDBC connection. This feature uses more resources than normal connection pool operations and will likely degrade connection pool performance, so it is not recommended for production use. This feature does not apply to connections created with a non-XA JDBC driver. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `ConnProfilingEnabled` | Default: false Dynamic: yes
Test Frequency | The number of seconds between database connection tests. After every `TestFrequencySeconds` interval, unused database connections are tested using `TestTableName`. Connections that do not pass the test will be closed and reopened to re-establish a valid physical database connection. If the test fails again, the connection is closed. If `TestTableName` is not set, the test will not be performed. If set to `0` (the default), connections are not tested. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `TestFrequencySeconds` | Units: seconds Minimum: 0 Maximum: 2147483647 Default: 0 Dynamic: yes
Test Reserved Connections | When selected (set to true), WebLogic Server tests a connection before giving it to the client. The test adds a small delay in serving the client's request for a connection from the pool, but ensures that the client receives a working connection (assuming that the DBMS is available and accessible). The attribute TestTableName must be enabled for TestConnectionsOnReserve to be effective. This attribute is required for connection pools used within a MultiPool that uses the High Availability algorithm. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `TestConnectionsOnReserve` | Default: false Valid values: true false Dynamic: yes
Test Created Connections | When selected (set to true), WebLogic Server tests a connection after creating it and before adding it to the list of connections available to the client. The test adds a small delay in creating the connection, but ensures that the client receives a working connection (assuming that the DBMS is available and accessible). The attribute TestTableName must be set for TestConnectionsOnCreate to be effective. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `TestConnectionsOnCreate` | Default: false Valid values: true false Dynamic: yes
Test Released Connections | When selected (set to true), WebLogic Server tests a connection before returning it to the connection pool. If all connections in the pool are already in use and a client is waiting for a connection, the client's wait will be slightly longer while the connection is tested. The attribute TestTableName must be enabled for TestConnectionsOnRelease to be effective. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `TestConnectionsOnRelease` | Default: false Valid values: true false Dynamic: yes
Connection Reserve Timeout | The number of seconds after which a call to reserve a connection from the connection pool will timeout. When set to `0`, a call will never timeout. When set to `-1`, a call will timeout immediately. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `ConnectionReserveTimeoutSeconds` | Units: seconds Minimum: -1 Maximum: 2147483647 Default: 10 Dynamic: yes
Connection Creation Retry Frequency | The number of seconds between attempts to create database connections when the connection pool is created. If you do not set this value, connection pool creation fails if the database is unavailable. If set and if the database is unavailable when the connection pool is created, WebLogic Server will attempt to create connections in the pool again after the number of seconds you specify, and will continue to attempt to create the connections until it succeeds. When set to `0` (the default), this feature is disabled. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `ConnectionCreationRetryFrequencySeconds` | Units: seconds Minimum: 0 Maximum: 2147483647 Default: 0 Dynamic: yes
Inactive Connection Timeout | The number of seconds of inactivity after which reserved connections will forcibly be released back into the pool. When set to `0` (the default), this feature is disabled. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `InactiveConnectionTimeoutSeconds` | Units: seconds Minimum: 0 Maximum: 2147483647 Default: 0 Dynamic: yes
Maximum Waiting for Connection | The maximum number of connection requests that can concurrently block waiting to reserve a connection from the pool. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `HighestNumWaiters` | Minimum: 0 Maximum: 2147483647 Default: 2147483647 Dynamic: yes
Maximum connections made unavailable | The maximum number of connections in the pool that can be made unavailable (to an application) for purposes like refreshing the connection, etc. Note that in cases likes the backend system being unavailable, this specified value could be exceeded due to factors outside the pool's control. When set to `0` (the default), this feature is disabled. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `HighestNumUnavailable` | Minimum: 0 Maximum: 2147483647 Default: 0 Dynamic: yes
Test Table Name | The name of the table used when testing a physical database connection. The default SQL code used to test a connection is `"select count(*) from TestTableName"` The `TestTableName` must exist and be accessible to the database user for the connection. Most database servers optimize this SQL to avoid a table scan, but it is still a good idea to set `TestTableName` to the name of a table that is known to have few rows, or even no rows. If `TestTableName` begins with `"SQL "`, then the rest of the string following that leading token will be taken as a literal SQL statement that will be used to test a connection. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `TestTableName` | Dynamic: no
Init SQL | The SQL code used to initialize a connection. If you specify a value for Init SQL, WebLogic Server will run the query when it creates a database connection. If no value is set for Init SQL, WebLogic Server does not run any SQL code to initialize the connection. Start the code with `SQL` followed by a space. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `InitSQL` | Dynamic: no
Keep XA Connection Till Transaction Complete Note: This option is available only when an XA JDBC driver is used to create the physical database connections in the connection pool. | Select this option to force a connection pool to reserve a physical connection and provide the same connection to an application throughout transaction processing until the distributed transaction is complete. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `keepXAConnTillTxComplete` | Default: false Dynamic: no
Need Transaction Context On Close Note: This option is available only when an XA JDBC driver is used to create the physical database connections in the connection pool. | Select this option if the XA driver used to create database connections requires a distributed transaction context when closing various JDBC objects (result sets, statements, connections, and so on). If selected, SQL exceptions that are thrown while closing JDBC objects without a transaction context will be swallowed. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `needTxCtxOnClose` | Default: false Dynamic: no
New XA Connection For Commit Note: This option is available only when an XA JDBC driver is used to create the physical database connections in the connection pool. | Select this option if the XA driver used to create database connections or the DBMS requires that a dedicated XA connection be used for commit/rollback processing of distributed transactions. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `newXAConnForCommit` | Default: false Dynamic: no
XA End Only Once Note: This option is available only when an XA JDBC driver is used to create the physical database connections in the connection pool. | Select this option if the XA driver used to create database connections or the DBMS requires that `XAResource.end()` is called only once for each pending `XAResource.start()`. If this option is selected, the XA driver will not call `XAResource.end(TMSUSPEND)`, `XAResource.end(TMSUCCESS)` successively. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `xAEndOnlyOnce` | Default: false Dynamic: no
Enable XA Transaction Timeout Note: This option is available only when an XA JDBC driver is used to create the physical database connections in the connection pool. | Select this option to enable setting a transaction branch timeout using the XA resource manager for the connection, typically the JDBC driver. When selected, the WebLogic Server Transaction Manager calls `XAResource.setTransactionTimeout()` before calling `XAResource.start`, and passes either the XA Transaction Timeout value or the global transaction timeout. See XA Transaction Timeout. You may want to set a transaction branch timeout if you have long-running transactions that exceed the default timeout value on the XA resource. Note: To use this feature, the resource manager (typically, the JDBC driver) must support the `javax.transaction.xa.XAResource.setTransactionTimeout()` method. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `XASetTransactionTimeout` | Default: false Dynamic: no
XA Transaction Timeout Note: This option is available only when an XA JDBC driver is used to create the physical database connections in the connection pool. | The number of seconds to set as the transaction branch timeout. If set, this value is passed as the transaction timeout value in the `XAResource.setTransactionTimeout()` call on the XA resource manager, typically the JDBC driver. When this value is set to `0`, the WebLogic Server Transaction Manager passes the global WebLogic Server transaction timeout in seconds in the method (see Timeout Seconds or JTA for more details). If set, this value should be greater than or equal to the global WebLogic Server transaction timeout. Note: You must select Enable XA Transaction Timeout to enable the XA Transaction Timeout attribute. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `XATransactionTimeout` | Default: `0` Dynamic: no
XA Retry Duration Seconds Note: This option is available only when an XA JDBC driver is used to create the physical database connections in the connection pool. | Determines the duration in seconds during which the transaction manager will retry to perform recover, rollback, and commit operations on the resource. A value of zero indicates that no retries will be performed. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `XARetryDurationSeconds` | Default: 60 Dynamic: no
XA Retry Interval Seconds Note: This option is available only when an XA JDBC driver is used to create the physical database connections in the connection pool. | Determines the time in seconds between XA retry operations if the `XARetryDurationSeconds` attribute is set to a positive value. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `XARetryDurationSeconds` | Default: false Dynamic: no
Keep Connection Open On Release Note: This option is available only when an XA JDBC driver is used to create the physical database connections in the connection pool. | Select this option if the XA driver used to create database connections or the DBMS requires that a logical JDBC connection be kept open while transaction processing continues (although the physical XA connection can returned to the XA connection pool). MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `keepLogicalConnOpenOnRelease` | Default: false Dynamic: no
Supports Local Transaction Note: This option is available only when an XA JDBC driver is used to create the physical database connections in the connection pool. | Select this option if the XA driver used to create physical database connections supports SQL without global transactions. MBean: `weblogic.management. configuration. JDBCConnectionPoolMBean` Attribute: `supportsLocalTransaction` | Default: false Dynamic: no