Sun GlassFish Enterprise Server v3 Prelude Administration Reference

Attributes

The following table describes attributes for the jdbc-connection-pool element. Changing the following attributes requires a server restart: datasource-classname, associate-with-thread, lazy-connection-association, and lazy-connection-enlistment.

Table 1–44 jdbc-connection-pool Attributes

Attribute 

Default 

Description 

name

none 

Specifies the name of the connection pool. A jdbc-resource element’s pool-name attribute refers to this name.

description

none 

(optional) Specifies a text description of this element. 

datasource-classname

none 

Specifies the class name of the associated vendor-supplied data source. This class must implement javax.sql.DataSource, javax.sql.XADataSource , javax.sql.ConnectionPoolDatasource, or a combination.

res-type

javax.sql.DataSource

(optional) Specifies the interface the data source class implements. The value of this attribute can be javax.sql.DataSource, javax.sql.XADataSource , or javax.sql.ConnectionPoolDatasource. If the value is not one of these interfaces, the default is used. An error occurs if this attribute has a legal value and the indicated interface is not implemented by the data source class.

steady-pool-size

8

(optional) Specifies the initial and minimum number of connections maintained in the pool. 

max-pool-size

32

(optional) Specifies the maximum number of connections that can be created to satisfy client requests. 

max-wait-time-in-millis

60000

(optional) Specifies the amount of time, in milliseconds, that the caller is willing to wait for a connection. If 0, the caller is blocked indefinitely until a resource is available or an error occurs.

pool-resize-quantity

2

(optional) Specifies the number of idle connections to be destroyed if the existing number of connections is above the steady-pool-size (subject to the max-pool-size limit).

This is enforced periodically at the idle-timeout-in-seconds interval. An idle connection is one that has not been used for a period of idle-timeout-in-seconds. When the pool size reaches steady-pool-size, connection removal stops.

idle-timeout-in-seconds

300

(optional) Specifies the maximum time that a connection can remain idle in the pool. After this amount of time, the pool can close this connection. 

This timeout value must be kept shorter than the server side (database) timeout value to prevent the accumulation of unusable connections in the application. 

transaction-isolation-level

default JDBC driver isolation level 

(optional) Specifies the transaction isolation level on the pooled database connections. Allowed values are read-uncommitted, read-committed , repeatable-read, or serializable.

Applications that change the isolation level on a pooled connection programmatically risk polluting the pool, which can lead to errors. See is-isolation-level-guaranteed for more details.

is-isolation-level-guaranteed

true

(optional) Applicable only when transaction-isolation-level is explicitly set. If true, every connection obtained from the pool is guaranteed to have the desired isolation level. This might impact performance on some JDBC drivers. Only set this attribute to false if you are certain that the hosted applications do not return connections with altered isolation levels.

is-connection-validation-required

false

(optional) Specifies whether connections have to be validated before being given to the application. If a resource’s validation fails, it is destroyed, and a new resource is created and returned. 

connection-validation-method

auto-commit

(optional) Legal values are as follows: 

  • auto-commit (default), which uses Connection.setAutoCommit(Connection.getAutoCommit())

  • meta-data, which uses Connection.getMetaData()

  • table, which performs a query on a table specified in the validation-table-name attribute

Because many JDBC drivers cache the results of auto-commit and meta-data calls, they do not always provide reliable validations. Check with the driver vendor to determine whether these calls are cached or not.

The table must exist and be accessible, but it doesn't require any rows. Do not use an existing table that has a large number of rows or a table that is already frequently accessed. More details can be found at Connection Validation in GlassFish JDBC.

validation-table-name

none 

(optional) Specifies the table name to be used to perform a query to validate a connection. This parameter is mandatory if and only if connection-validation-method is set to table.

fail-all-connections

false

(optional) If true, closes all connections in the pool if a single validation check fails. This parameter is mandatory if and only if is-connection-validation-required is set to true.

non-transactional-connections

false

(optional) If true, non-transactional connections can be made to the JDBC connection pool. These connections are not automatically enlisted with the transaction manager.

allow-non-component-callers

false

(optional) If true, non-Java-EE components, such as servlet filters, lifecycle modules, and third party persistence managers, can use this JDBC connection pool. The returned connection is automatically enlisted with the transaction context obtained from the transaction manager. Standard Java EE components can also use such pools. Connections obtained by non-component callers are not automatically closed at the end of a transaction by the container. They must be explicitly closed by the caller.

connection-leak-timeout-in-seconds

0

Detects potential connection leaks by the application. A connection that is not returned back to the pool by the application within the specified period is assumed to be potentially leaking, and a stack trace of the caller is logged. A zero value disables leak detection. A nonzero value enables leak tracing. 

Use this attribute along with connection-leak-reclaim to avoid potential connection leaks from the application. More details are at Connection Leak Tracing.

connection-leak-reclaim

false

If true, the pool will reclaim a connection after connection-leak-timeout-in-seconds occurs.

connection-creation-retry-attempts

0

Specifies the number of attempts to create a new connection in case of a failure. 

connection-creation-retry-interval-in-seconds

10

Specifies the time interval between attempts to create a connection when connection-creation-retry-attempts is greater than 0.

validate-atmost-once-period-in-seconds

0

Specifies the time interval within which a connection is validated at most once. Minimizes the number of validation calls. 

statement-timeout-in-seconds

-1

Sets the query timeout property of a statement to enable termination of abnormally long running queries. The default value of -1 disables this feature.

An abnormally long running JDBC query executed by an application may leave it in a hanging state unless a timeout is explicitly set on the statement. This attribute guarantees that all queries automatically time out if not completed within the specified period. When statements are created, the queryTimeout is set according to the value specified in this attribute. This works only when the underlying JDBC driver supports queryTimeout for Statement, PreparedStatement, CallableStatement, and ResultSet.

lazy-connection-enlistment

false

If true, a connection is not enlisted in a transaction until it is used. If false, any connection object available to a transaction is enlisted in the transaction.

lazy-connection-association

false

If true, a physical connection is not associated with a logical connection until it is used. If false, a physical connection is associated with a logical connection even before it is used.

associate-with-thread

false

Specifies whether a connection is associated with the thread to enable the thread to reuse the connection. If true, allows a connection to be saved as a ThreadLocal in the calling thread. This connection gets reclaimed only when the calling thread dies or when the calling thread is not in use and the pool has run out of connections. If false, the thread must obtain a connection from the pool each time the thread requires a connection.

This attribute associates a connection with a thread such that when the same thread is in need of a connection, it can reuse the connection already associated with that thread. In this case, the overhead of getting a connection from the pool is avoided. However, when this value is set to true, you should verify that the value of the max-pool-size attribute is comparable to the max-thread-pool-size attribute of the thread-pool element. If the max-thread-pool-size value is much higher than the max-pool-size value, a lot of time is spent associating a connection with a new thread after dissociating it from an older one. Use this attribute in cases where the thread pool should reuse connections to avoid this overhead.

match-connections

false

Specifies whether a connection that is selected from the pool should be matched with the connections with certain credentials. If true, enables connection matching. You can set to false if connections are homogeneous.

If the connection pool is used by applications that have multiple user credentials, match-connections must be true. The connection pool matches the request's credential with the connections in the pool and returns a matched connection for use. For new requests with different credentials, unmatched free connections are automatically purged to provide new connections to satisfy the new requests. This attribute need not be true if it is known that there is only one credential used by the applications and therefore the pool has homogeneous connections.

max-connection-usage-count

0

Specifies the number of times a connections is reused by the pool, after which it is closed. A zero value disables this feature. By limiting the maximum number of times a connection can be reused, you can avoid statement leaks if the application does not close statements. 

wrap-jdbc-objects

false

If true, wrapped JDBC objects are returned for Statement, PreparedStatement, CallableStatement, ResultSet, and DatabaseMetaData.

This option ensures that Statement.getConnection() is the same as DataSource.getConnection(). Therefore, this option should be true when both Statement.getConnection() and DataSource.getConnection() are done. The default is false to avoid breaking existing applications.