New JDBC Connection Pool: Add Connection Pool Optional Settings
See Also
This page of the New File wizard for defining a JDBC connection pool
allows you to modify the default values for
pool settings, transaction isolation, and connection validation. It is best to
leave these settings at their default values and modify them later
in the connection pool properties window.
The following settings can be modified in this screen:
Pool Settings
A set of physical database connections reside in the pool.
When an application requests a connection, the connection is
removed from the pool, and when the application releases the
connection, it is returned to the pool.
- Steady Pool Size. An integer value representing the number of
connections in the pool at any given moment. Usually, this is the
minimum connections in the pool.
- Max Pool Size. An integer value representing the maximum number
of connections in the pool.
- Max Wait time. An integer value representing the maximum wait
time in milliseconds.
- Pool Resize Quantity. Connection pools, as they shrink to the
minimum pool size, are resized in batches. This number represents the
number of connections in the batch for resizing the pool. A batch size
that is too large may delay connection recycling, while a batch size
too small may be less efficient.
- Idle Timeout (seconds). An integer value representing the maximum
idle timeout length in seconds. This is the amount of time that a
connection may remain idle in the pool. Connections that remain idle
for longer than this time are closed.
Transaction Isolation
Because a database is usually accessed by many users
concurrently, one transaction might update data while another
attempts to read the same data. The isolation level of a
transaction defines the degree to which the data being updated
is visible to other transactions. For details on isolation levels,
refer to the documentation of the database vendor.
- Transaction Isolation. Select one of the following
from the dropdown list: JDBC Driver Default, read-uncommitted, read-committed,
repeatable-read, serializable.
- Guarantee Isolation Level. Set to true or false.
If you set to true, all connections taken from the pool have
the same isolation level. For example, if the isolation level
for the connection is changed programatically
(with con.setTransactionIsolation) when last used,
this mechanism changes the status back to the specified
isolation level.
Connection Validation
The application server can validate connections before
they are passed to applications. Validation allows the application
server to automatically re-establish database connections if the
database becomes unavailable due to network failure or database
server crash. Validation of connections incurs additional
overhead and slightly reduces performance.
- Connection Validation Required. Set to true or false. When set to
true, the application server validates connections before they are sent
to an application. When validation is in force, the application
server can automatically reinstate connections to databases that fail
due to network or database server failures.
- Validation Method. Select the validation method from the
pull-down list. There are three valid methods: auto-commit, meta-data,
and table.
- auto-commit and meta-data. The application server validates a
connection by calling the con.getAutoCommit() and con.getMetaData()
methods. However, since the results of
these calls may be cached, they do not always provide reliable
validations.
- table The application queries a database table you’ve
specified, using the query: select (count *) from <table-name>.
While the table must exist and be accessible, it need not have any rows. Do not
use an existing table that has a large number of rows or
a table that is already frequently accessed.
- Table Name. This is the name of the connection validation table. Set the table
name if you selected table as the validation method.
- Fail All Connections. Set to true or false. When set to
true, if a single connection fails, the application server closes all
connections in the pool and then reestablishes them. When set to
false, only individual connections are reestablished.
- Non Transactional Connections. Set to true or false.
When set to true, connections are not automatically enlisted and delisted in transaction contexts.
A non-transactional connection can be used to query the database while a transaction is still in progress (before the transaction commits).
Non-transactional connections are not automatically returned to the pool and need to be explicitly closed by the application.
The default is false.
- Allow Non Component Callers. Set to true or false.
When set to true, the connection pool can be accessed remotely by non-Java-EE components (components other than EJBs and servlets).
The returned connection is automatically enlisted with the transaction context obtained from the transaction manager.
The default is false.
- See Also
- Defining a Connection Pool
- Choose Database Connection
- Add Connection Pool Properties
Legal Notices