The number of seconds between attempts to establish connections
to the database.

If you do not set this value, data source creation fails if the
database is unavailable. If set and if the database is unavailable
when the data source 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.

Enables credential mapping for the data source. When an
application requests a database connection, WebLogic Server sets a
light-weight client ID on the database connection based on a map of
database IDs.

You must also specify the map of WebLogic Server user IDs to
database user IDs (credential mapping).

This feature relies on features in the JDBC driver and DBMS. It
is not supported with all drivers and DBMSs.

Specifies the absolute name of the application class used to
intercept method calls to the JDBC driver. The application
specified must implement the
weblogic.jdbc.extensions.DriverInterceptor interface.

Weblogic Server will invoke the preInvokeCallback(),
postInvokeExceptionCallback(), and postInvokeCallback() methods of
the registered application before and after invoking any method
inside the JDBC driver. You can use this feature to profile JDBC
driver usage and monitor:

The number of inactive seconds on a reserved connection before
WebLogic Server reclaims the connection and releases it back into
the connection pool.

You can use the Inactive Connection Timeout feature to reclaim
leaked connections - connections that were not explicitly closed by
the application. Note that this feature is not intended to be used
in place of properly closing connections.

SQL statement to execute that will initialize newly created
physical database connections. Start the statement with SQL
followed by a space.

If the Init SQL value 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 initialize database
connections. If the Init SQL value does not begin with "SQL ", the
value will be treated as the name of a table and the following SQL
statement will be used to initialize connections:
"select count(*) from InitSQL"

The table InitSQL 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 InitSQL to the name of a table that is
known to have few rows, or even no rows.

PinnedToThread is an option that can improve performance by
enabling execute threads to keep a pooled database connection even
after the application closes the logical connection.

When PinnedToThread is enabled, WebLogic Server pins a database
connection from the connection pool to an execution thread the
first time an application uses the thread to reserve a connection.
When the application finishes using the connection and calls
connection.close(), which otherwise returns the connection to the
connection pool, WebLogic Server keeps the connection with the
execute thread and does not return it to the connection pool. When
an application subsequently requests a connection using the same
execute thread, WebLogic Server provides the connection already
reserved by the thread.

With PinnedToThread, there is no locking contention on the
connection pool that occurs when multiple threads attempt to
reserve a connection at the same time and there is no contention
for threads that attempt to reserve the same connection from a
limited number of database connections.

If an application concurrently reserves more than one connection
from the connection pool using the same execute thread, WebLogic
Server creates additional database connections and pins them to the
thread, as well.

JDBCLegalHelper.PROFILE_TYPE_CONN_LAST_USAGE - Profile the
previous thread that last used the connection. This information is
useful when debugging problems with connections infected with
pending transactions that cause subsequent XA operations on the
connections to fail.

JDBCLegalHelper.PROFILE_TYPE_CONN_MT_USAGE - Profile threads
that erroneously use a connection previously obtained by a
different thread.

Specifies whether a connection will be removed from the
connection pool after the application uses the underlying vendor
connection object.

If you disable removing infected connections, you must make sure
that the database connection is suitable for reuse by other
applications.

When set to true (the default), 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.

When set to false, when the application closes the
logical connection, the physical connection is returned to the
connection pool and can be reused by the application or by another
application.

The number of seconds within a connection use that WebLogic
Server trusts that the connection is still viable and will skip the
connection test, either before delivering it to an application or
during the periodic connection testing process.

This option is an optimization that minimizes the performance
impact of connection testing, especially during heavy traffic.

The time after which a statement currently being executed will
time out.

StatementTimeout relies on underlying JDBC driver support.
WebLogic Server passes the time specified to the JDBC driver using
the java.sql.Statement.setQueryTimeout() method. If
your JDBC driver does not support this method, it may throw an
exception and the timeout value is ignored.

The number of seconds between when WebLogic Server tests unused
connections. (Requires that you specify a Test Table Name.)
Connections that fail the test are closed and reopened to
re-establish a valid physical connection. If the test fails again,
the connection is closed.

In the context of multi data sources, this attribute controls
the frequency at which WebLogic Server checks the health of data
sources it had previously marked as unhealthy.

The name of the database table to use when testing physical
database connections. This name is required when you specify a Test
Frequency and enable Test Reserved Connections.

The default SQL code used to test a connection is "select
count(*) from TestTableName"

Most database servers optimize this SQL to avoid a table scan,
but it is still a good idea to set the Test Table Name to the name
of a table that is known to have few rows, or even no rows.

If the Test Table Name 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 connections instead
of the standard query.