schemas.jdbc-data-source.1.2.jdbc-data-source.xsd Maven / Gradle / Ivy
Copyright 2011 Oracle, Inc. All rights reserved.
This is the XML Schema for the WebLogic Datasource configuration.
The root element for JDBC Datasource.
The root element for JDBC Datasource.
A unique name that identifies this data source in the
WebLogic domain.
Configuration parameters for the JDBC Driver used by this data
source.
Configuration parameters for the JDBC Driver used by this data
source.
Configuration parameters for this data source's connection pool.
Configuration parameters for the basic usage of this data source.
Configuration parameters for this data source's XA-related behavior.
Configuration parameters for this data source's Oracle-related
behavior.
Immutable identifier for the datasource.
Configuration parameters for the JDBC Driver used by this data
source.
The URL of the database to connect to. The format of the URL
varies by JDBC driver.
The URL is passed to the JDBC driver to create the physical
database connections.
The full package name of JDBC driver class used to create
the physical database connections in the connection pool in the
data source.
For example:
oracle.jdbc.OracleDriver
The driver must be the name of a class that implements the
java.sql.Driver interface. Check the driver documentation
to find the full pathname.
Note that the driver class must be in the classpath of any server
to which the data source is deployed.
The list of properties passed to the
JDBC driver when creating physical database connections.
To enable driver-level features, add the driver property and its value
to the Properties list. WebLogic Server sets driver-level properties
in the Properties list * on the driver's ConnectionPoolDataSource object.
Note: For Security reasons, when WebLogic Server
is running in Production mode, you cannot specify database
passwords in this properties list. Data source deployment will
fail if a password is specified in the properties list.
To override this security check, use the
command line argument "weblogic.management.allowClearTextPasswords"
when starting the server.
The encrypted database password as set with setPassword(),
setPasswordEncrypted(byte[] bytes), or as a key=value pair
in the list of JDBC driver properties.
Specifies that WebLogic Server should use the XA interface of the
JDBC driver.
If the JDBC driver class used to create database connections
implements both XA and non-XA versions of a JDBC driver, you can set
this attribute to indicate that WebLogic Server should treat the
JDBC driver as an XA driver or as a non-XA driver.
Specifies whether the database credentials are to be obtained from
the credential mapper using the "user" property as the key. When
true, the credentials are obtained from the credential mapper.
When false, the database user name and password are obtained from
the "user" property and Password element, respectively.
JDBC connection property.
JDBC connection property consisting of name and value.
JDBC connection property consisting of name and value.
The name of the property. The name of each property must be
unique in the list of properties.
The value of the property.
The value of the property defined as a system property.
Configuration parameters for this data source's connection pool.
The number of physical connections to create when
creating the connection pool in the data source. If unable to
create this number of connections, creation of the data source
will fail.
The maximum number of physical connections that this
connection pool can contain.
The minimum number of physical connections that this
connection pool can contain after shrinking.
The number of connections created when new connections are
added to the connection pool.
When there are no more available physical connections to satisfy
connection requests, WebLogic Server creates this number of additional
physical connections and adds them to the connection pool.
In WebLogic Server 10.3.1 and higher releases, the
capacityIncrement is no longer configurable and
is set to a value of 1.
This attribute is deprecated.
The number of seconds to wait before shrinking a connection pool
that has incrementally increased to meet demand.
When set to 0, shrinking is disabled.
The maximum number of connection requests that can concurrently
block threads while waiting to reserve a connection from the
data source's connection pool.
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.
When set to 0, connection retry is disabled.
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.
The number of seconds a WebLogic Server instance waits between
attempts when testing 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.
When set to 0, the feature is disabled.
Enables WebLogic Server to test a connection before
giving it to a client. (Requires that you specify a Test Table Name.)
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
viable connection.
The number of seconds between when WebLogic Server harvests profile
data.
When set to 0, harvesting of data is disabled.
Enables the data source to be shutdown even if connections obtained
from the pool are still in use.
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.
When set to 0, the feature is disabled.
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.
For example: SQL BEGIN; Null; END;
The number of seconds to delay before creating each physical
database connection. This delay supports database servers that
cannot handle multiple connection requests in rapid succession.
The delay takes place both during initial data source
creation and during the lifetime of the data source whenever
a physical database connection is created.
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.
The number of prepared and callable statements stored in the
cache. (This may increase server performance.)
WebLogic Server can reuse statements in the cache without
reloading the statements, which can increase server performance.
Each connection in the connection pool has its own cache of
statements.
Setting the size of the statement cache to 0 turns off
statement caching.
The algorithm used for maintaining the prepared statements
stored in the statement cache.
Options are:
LRU - when a new prepared or callable statement is used,
the least recently used statement is replaced in the cache.
FIXED - the first fixed number of prepared and callable
statements are cached.
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.
A value of -1 disables this feature.
A value of 0 means that statements will not time out.
Specifies that type of profile data to be collected for the
JDBC subsystem.
You can specify combinations of the following profile types:
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_USAGE
Profile threads currently using connections from the
pool of connections in the data source.
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_RESV_WAIT
Profile threads currently waiting to reserve
a connection from the data source.
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_LEAK
Profile threads that have reserved a connection from
the data source and the connection leaked (was not properly returned
to the pool of connections).
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_RESV_FAIL
Profile threads that attempt to reserve a connection
from the data source but fail.
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_STMT_CACHE_ENTRY
Profile prepared and callable statements added to the statement
cache, and profile the threads that originated the cached statements.
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_STMT_USAGE
Profile threads currently executing SQL statements from
the statement cache.
weblogic.jdbc.common.internal.JDBCConstants.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.
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_MT_USAGE
Profile threads that erroneously use a connection previously obtained
by a different thread.
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_NONE
Disable profiling for the data source.
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_ALL
Enable all profile types for the data source.
Specifies level of JDBC debugging for XA drivers, where larger
values in the range provide more debugging information.
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:
Methods being executed
Any exceptions thrown
Time spent inside the driver executing methods
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 execute thread and does not return it to
the connection pool.
When an application subsequently requests a connection using the
same execute thread, 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.
Enables identity-based-connection-pooling for the data source.
When an application requests a database connection, WebLogic Server
picks or creates a physical connection with requested DBMS identity
based on a map of WebLogic user IDs and database IDs.
You must also specify the map of WebLogic Server user IDs to
database user IDs (credential mapping).
This element was introduced in the 9.0.1 version of WebLogic
Server. It should not be used in instance documents that may be
consumed by prior WebLogic Server versions.
By default, data type objects for Array, Blob, Clob, NClob, Ref,
SQLXML, and Struct, plus ParameterMetaData and ResultSetMetaData objects
are wrapped with a WebLogic wrapper. This allows for features like
debugging and connection usage to be done by the server.
The wrapping can be turned off by setting this value to false.
This improves performance, in some cases significantly, and allows
for the application to use the native driver objects directly.
This value is used to configure error codes to be treated as
fatal errors so that a connection is not put back in the pool.
It is a comma separated list of error codes.
The "fatal-error-codes" tag defines the fatal error codes that
when specified as the exception code
within a SQLException (retrieved by sqlException.getErrorCode())
indicates that a fatal error has occurred and the database is no
longer reachable. The "fatal-error-codes" tag is optional.
The name of the connection labeling callback.
This is automatically passed to registerConnectionLabelingCallback
when the datasource is created.
The maximum number of connections that may be harvested when the
connection harvesting occurs. The range of valid values is 1 to
maxCapacity. Defaults to 1.
The number of available connections below which the connection
pool's connection harvesting will occur. The range of valid
values is 0 to maxCapacity. Defaults to -1.
Setting the value to -1 disables connection
harvesting.
Configuration parameters for the basic usage of this data source.
The JNDI path to where this Data Source is bound.
By default, the JNDI name is the name of the data source.
Applications that look up the JNDI path will get a
javax.sql.DataSource instance that corresponds to this
data source.
Specifies the scoping of the data source.
You can specify one of the following scopes:
Global
Specifies that the data source is bound in the cluster-wide JNDI
tree with the JNDIName specified so that the data source is
available for use to any JDBC client across the cluster.
This is the default setting.
Application
Specifies that the data source is bound in the application's
local namespace with the JNDIName specified so that the data source
is available for use only by JDBC clients within the
application. This can only be used for packaged datasources and
is ignored for JDBC System resources.
Enables multiple rows to be "prefetched" (that is,
sent from the server to the client) in one server access.
When an external client accesses a database using JDBC through
WebLogic Server, row prefetching improves performance by fetching
multiple rows from the server to the client in one server access.
WebLogic Server ignores this setting and does not use row
prefetching when the client and WebLogic Server are in the same
JVM.
If row prefetching is enabled, specifies the number of
result set rows to prefetch for a client.
The optimal prefetch size depends on the particulars of the query. In
general, increasing this number will increase performance, until a
particular value is reached. At that point further increases do not
result in any significant performance increase. Very rarely will
increased performance result from exceeding 100 rows. The default
value should be reasonable for most situations.
Specifies the data chunk size for steaming data types.
Streaming data types (for example resulting from a call to
getBinaryStream()) are sent in sized chunks from
WebLogic Server to the client as needed.
The algorithm determines the connection request processing for
the multi data source.
You can specify one of the following algorithm types:
Failover
Connection requests are sent to the first data source in the
list; if the request fails, the request is sent to the next data
source in the list, and so forth. The process is repeated until a
valid connection is obtained, or until the end of the list is
reached, in which case an exception is thrown.
Load balancing
The multi data source distributes connection requests evenly to
its member data sources. With this algorithm, the multi data source
also provides failover processing. That is, if a request fails, the
multi data source sends the request to the next data source in the
list until a valid connection is obtained, or until the end of the
list is reached, in which case an exception is thrown.
The list of data sources to which the multi data source will
route connection requests. The order of data sources in the list
determines the failover order.
The name of the application class to handle the callback sent
when a multi data source is ready to failover or fail back
connection requests to another data source within the multi data
source.
The name must be the absolute name of an application class that
implements the
weblogic.jdbc.extensions.ConnectionPoolFailoverCallback
interface.
For multi data sources with the failover algorithm,
enables the multi data source to failover connection requests to
the next data source if all connections in the current data source
are in use.
Determines the transaction protocol (global transaction
processing behavior) for the data source. Options include:
TwoPhaseCommit - Standard XA transaction processing. Requires an
XA driver.
LoggingLastResource - A performance enhancement for one non-XA
resource.
EmulateTwoPhaseCommit - Enables one non-XA resource to
participate in a global transaction, but has some risk to data.
OnePhaseCommit - One-phase XA transaction processing using a
non-XA driver. This is the default setting.
None - Support for local transactions only.
Enables WebLogic Server to keep the physical
database connection associated with the logical connection
when committing a local transaction instead releasing it
and getting another physical connection when needed.
Setting this option to true may require additional connections
to be configured on the database.
Use this setting to work around specific problems with
JDBC XA drivers.
Enables WebLogic Server to keep the physical
database connection associated with the logical connection
when committing a global transaction instead releasing it
and getting another physical connection when needed.
Setting this option to true may require additional connections
to be configured on the database.
Configuration parameters for this data source's XA-related behavior.
Enables WebLogic Server to associate the same XA
database connection from the connection pool
with a global transaction until the transaction
completes.
Only applies to connection pools that use an XA
driver.
Use this setting to work around specific problems with
JDBC XA drivers.
Specifies whether the XA driver requires a distributed
transaction context when closing various JDBC objects (result sets,
statements, connections, and so forth). Only applies to connection
pools that use an XA driver.
When enabled, SQL exceptions that are thrown while closing the
JDBC objects without a transaction context will be suppressed.
Use this setting to work around specific problems with
JDBC XA drivers.
Specifies that XAResource.end() is called only once for
each pending XAResource.start().
This option prevents the XA driver from
calling XAResource.end(TMSUSPEND) and
XAResource.end(TMSUCCESS) successively. Only applies to
data sources that use an XA driver.
Use this setting to work around specific problems with
JDBC XA drivers.
Specifies that a dedicated XA connection is used for
commit and rollback processing for a global transaction.
Only applies to data sources that use an XA driver.
Use this setting to work around specific problems with
JDBC XA drivers.
Enables WebLogic Server to keep the logical JDBC connection open
for a global transaction when the physical XA connection is returned
to 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 be returned to the connection pool).
Only applies to data sources that use an XA driver.
Use this setting to work around specific problems with
JDBC XA drivers.
Enables JTA resource health monitoring for
an XA data source.
When enabled, if an XA resource fails to respond to an XA call
within the period specified in MaxXACallMillis, WebLogic Server
marks the data source as unhealthy and blocks any further calls
to the resource.
This property applies to XA data sources only, and is ignored
for data sources that use a non-XA driver.
Specifies that the transaction manager calls recover on the resource
only once. Only applies to data sources that use an XA
driver.
Use this setting to work around specific problems with
JDBC XA drivers.
Enables WebLogic Server to set a transaction branch timeout based
on the value for XaTransactionTimeout.
When enabled, 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.
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.
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.
If set, this value should be greater than or equal to the
global WebLogic Server transaction timeout.
Note: You must enable XaSetTransactionTimeout to enable setting the
transaction branch timeout.
Enables WebLogic Server to call rollback()
on the connection before returning the connection to the
connection pool.
Enabling this attribute will have a performance impact as the
rollback call requires communication with the database server.
This option is deprecated. Its value is currently ignored.
Determines the duration in seconds for which the transaction manager
will perform recover operations on the resource. A value of zero
indicates that no retries will be performed.
The number of seconds between XA retry operations if
XARetryDurationSeconds is set to a positive value.
Configuration parameters for this data source's Oracle-related behavior.
Enables the data source to subscribe to and process Oracle FAN
events.
This attribute is only applicable for RAC configurations that
publish FAN notification events using the ONS protocol.
A comma-separate list of ONS daemon listen addresses and ports to
which connect to for receiving ONS-based FAN events.
The location of the Oracle wallet file in which the SSL
certificates are stored. Only required when the ONS client is
configured to communicate with ONS daemons using SSL.
The encrypted database password as set with setOnsWalletPassword(),
or with setOnsWalletPasswordEncrypted(byte[] bytes).
Enables the Oracle JDBC JavaNet Fastpath to reduce data copies
and fragmentation.
Enables the Oracle JDBC optimize UTF-8 conversion option.
The name of the connection initialization callback.
This is automatically passed to registerConnectionInitializationCallback
when the datasource is created.
The preferred affinity policy for the data source.
Enables the Oracle JDBC Proxy Authentication option.
When getting a connection, use database credentials instead of application server credentials.
© 2015 - 2025 Weber Informatics LLC | Privacy Policy