PK
yIoa, mimetypeapplication/epub+zipPK yI META-INF/container.xml
This chapter provides information on how to properly tune the connection pool attributes in JDBC data sources in your WebLogic Server domain to improve application and system performance.
The following sections include information about tuning options for the connection pool in a JDBC data source:
When you use a prepared statement or callable statement in an application or EJB, there is considerable processing overhead for the communication between the application server and the database server and on the database server itself. To minimize the processing costs, WebLogic Server can cache prepared and callable statements used in your applications. When an application or EJB calls any of the statements stored in the cache, WebLogic Server reuses the statement stored in the cache. Reusing prepared and callable statements reduces CPU usage on the database server, improving performance for the current statement and leaving CPU cycles for other tasks.
Each connection in a data source has its own individual cache of prepared and callable statements used on the connection. However, you configure statement cache options per data source. That is, the statement cache for each connection in a data source uses the statement cache options specified for the data source, but each connection caches it's own statements. Statement cache configuration options include:
Statement Cache Type—The algorithm that determines which statements to store in the statement cache. See Statement Cache Algorithms.
Statement Cache Size—The number of statements to store in the cache for each connection. The default value is 10
. See Statement Cache Size.
You can use the Administration Console to set statement cache options for a data source. See "Configure the statement cache for a JDBC data source" in the Oracle WebLogic Server Administration Console Help.
The Statement Cache Type (or algorithm) determines which prepared and callable statements to store in the cache for each connection in a data source. You can choose from the following options:
When you select LRU (Least Recently Used, the default) as the Statement Cache Type, WebLogic Server caches prepared and callable statements used on the connection until the statement cache size is reached. When an application calls Connection.prepareStatement()
, WebLogic Server checks to see if the statement is stored in the statement cache. If so, WebLogic Server returns the cached statement (if it is not already being used). If the statement is not in the cache, and the cache is full (number of statements in the cache = statement cache size), WebLogic Server determines which existing statement in the cache was the least recently used and replaces that statement in the cache with the new statement.
The LRU statement cache algorithm in WebLogic Server uses an approximate LRU scheme.
When you select FIXED as the Statement Cache Type, WebLogic Server caches prepared and callable statements used on the connection until the statement cache size is reached. When additional statements are used, they are not cached.
With this statement cache algorithm, you can inadvertently cache statements that are rarely used. In many cases, the LRU algorithm is preferred because rarely used statements will eventually be replaced in the cache with frequently used statements.
The Statement Cache Size attribute determines the total number of prepared and callable statements to cache for each connection in each instance of the data source. By caching statements, you can increase your system performance. However, you must consider how your DBMS handles open prepared and callable statements. In many cases, the DBMS will maintain a cursor for each open statement. This applies to prepared and callable statements in the statement cache. If you cache too many statements, you may exceed the limit of open cursors on your database server.
For example, if you have a data source with 10 connections deployed on 2 servers, if you set the Statement Cache Size to 10 (the default), you may open 200 (10 x 2 x 10) cursors on your database server for the cached statements.
Using the statement cache can dramatically increase performance, but you must consider its limitations before you decide to use it. Please note the following restrictions when using the statement cache.
There may be other issues related to caching statements that are not listed here. If you see errors in your system related to prepared or callable statements, you should set the statement cache size to 0
, which turns off statement caching, to test if the problem is caused by caching prepared statements.
Prepared statements stored in the cache refer to specific database objects at the time the prepared statement is cached. If you perform any DDL (data definition language) operations on database objects referenced in prepared statements stored in the cache, the statements may fail the next time you run them. For example, if you cache a statement such as select * from emp
and then drop and recreate the emp
table, the next time you run the cached statement, the statement may fail because the exact emp
table that existed when the statement was prepared, no longer exists.
Likewise, prepared statements are bound to the data type for each column in a table in the database at the time the prepared statement is cached. If you add, delete, or rearrange columns in a table, prepared statements stored in the cache are likely to fail when run again.
These limitations depend on the behavior of your DBMS.
If you cache a prepared statement that uses a setNull
bind variable, you must set the variable to the proper data type. If you use a generic data type, as in the following example, data may be truncated or the statement may fail when it runs with a value other than null.
java.sql.Types.Long sal=null
.
.
.
if (sal == null)
setNull(2,int)//This is incorrect
else
setLong(2,sal)
Instead, use the following:
if (sal == null) setNull(2,long)//This is correct else setLong(2,sal)
When WebLogic Server caches a prepared or callable statement, the statement may open a cursor in the database. If you cache too many statements, you may exceed the limit of open cursors for a connection. To avoid exceeding the limit of open cursors for a connection, you can change the limit in your database management system or you can reduce the statement cache size for the data source.
To make sure that the database connections in a data source remain healthy, you should periodically test the connections. WebLogic Server includes two basic types of testing:
Automatic testing that you configure with options on the data source so that WebLogic Server makes sure that database connections remain healthy.
Manual testing that you can do to trouble-shoot a data source.
The following section discusses automatic connection testing options. For more information about manual connection testing, see Testing Data Sources and Database Connections.
To configure automatic testing options for a data source, you set the following options either through the Administration Console or through WLST using the JDBCConnectionPoolParamsBean
:
Test Frequency—(TestFrequencySeconds
in the JDBCConnectionPoolParamsBean
) Use this attribute to specify the number of seconds between tests of unused connections. WebLogic Server tests unused connections, and closes and replaces any faulty connections. You must also set the Test Table Name.
Test Reserved Connections—(TestConnectionsOnReserve
in the JDBCConnectionPoolParamsBean
) Enable this option to test each connection before giving to a client. This may add a slight delay to the request, but it guarantees that the connection is healthy. You must also set a Test Table Name.
Test Table Name—(TestTableName
in the JDBCConnectionPoolParamsBean
) Use this attribute to specify a table name to use in a connection test. You can also specify SQL code to run in place of the standard test by entering SQL
followed by a space and the SQL code you want to run as a test. Test Table Name is required to enable any database connection testing.
Seconds to Trust an Idle Pool Connection—(SecondsToTrustAnIdlePoolConnection
in the JDBCConnectionPoolParamsBean
) Use this option to specify the number of seconds after a connection has been proven to be OK that WebLogic Server trusts 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. See Minimizing Connection Request Delay with Seconds to Trust an Idle Pool Connection.
See the JDBC Data Source: Configuration: Connection Pool page in the Administration Console or see "JDBCConnectionPoolParamsBean" in the Oracle WebLogic Server MBean Reference for more details about these options.
For instructions to set connection testing options, see "Configure testing options for a JDBC data source" in the Oracle WebLogic Server Administration Console Help.
When WebLogic Server tests database connections in a data source, it reserves a connection from the data source, runs a small query on the connection, then returns the connection to the pool in the data source. The server instance tracks statistics on the pool status, including the amount of time a required to complete a connection test, the number of connections waiting for a connection, and the number of connections being tested. The history of recent test connection behavior is used to calculate the amount of time the server instance waits until a connection test is determined to have failed.
If a thread appears to be taking longer than normal to connect, the server instance may delay testing on other threads until the abnormally long-running test completes. If that thread hangs too long in connection testing (10 seconds by default), a pool may declare a DBMS connectivity failure, disable itself, and kill all connections, whether unreserved or in application hands.
This is very rare, and is intended to relieve the otherwise interminable hangs that can be caused by network cable disconnects and other problems that can lock any JVM thread which is doing a call in a socket read that the JVM will be unable to break until the OS TCP limit is hit (typically 10 minutes). If a pool disables itself in this manner, it will periodically try to reconnect to the DBMS (every 5 seconds by default). Once a new connection can be made, the pool will re-enable itself, and subsequent connection requests will be served as normal (with the pool repopulating itself as load requires).
The query used in testing is determined by the value in Test Table Name. If the value is a table name, the query is select 1 from table_name
. If Test Table Name includes a full query starting with SQL
followed by space and the query, WebLogic Server uses that query when testing database connections.
If a connection fails the test, WebLogic Server closes and recreates the connection, and then tests the new connection.
Details about the semantics of connection testing is discussed in the following sections:
Minimized Connection Test Delay After Database Connectivity Loss
Minimized Connection Request Delay After Connection Test Failures
Minimized Connection Request Delays After Loss of DBMS Connectivity
Minimizing Connection Request Delay with Seconds to Trust an Idle Pool Connection
When connections are created in a data source, WebLogic Server tests each connection using the query defined by the value in Test Table Name. Connections are created when a data source is deployed, either at server startup or when creating a data source, when increasing capacity to meet demand for connections, or when recreating a connection that failed a connection test.
The purpose of this testing is to ensure that new connections are viable and ready for use when an application requests a connection.
If Test Frequency
is greater than 0, WebLogic Server periodically tests the pooled connections that are not currently reserved by applications. The test is based on the query defined in Test Table Name. If a connection fails the test, WebLogic Server closes the connection, recreates the connection, and tests the new connection before returning it to the pool.
When Test Connections On Reserve
is enabled, when your application requests a connection from the data source, WebLogic Server tests the connection using the query specified in Test Table Name before giving the connection to the application. The default value is not enabled.
Testing reserved connections can cause a delay in satisfying connection requests, but it makes sure that the connection is viable when the application gets the connection. You can minimize the impact of testing reserved connections by tuning Seconds to Trust an Idle Pool Connection. See Minimizing Connection Request Delay with Seconds to Trust an Idle Pool Connection.
When connectivity to the DBMS is lost, even if only momentarily, some or all of the JDBC connections in a data source typically become defunct. If the data source is configured to test connections on reserve, when an application requests a database connection, WebLogic Server tests the connection, discovers that the connection is dead, and tries to replace it with a new connection to satisfy the request. Ordinarily, when the DBMS comes back online, the refresh process succeeds. However, in some cases and for some modes of failure, testing a dead connection can impose a long delay.
To minimize this delay, WebLogic data sources include logic that considers all connections in the data source as dead after a number of consecutive test failures, and closes all connections in the data source. After all connections are closed, when an application requests a connection, the data source creates a connection without first having to test a dead connection. This behavior minimizes the delay for connection requests following the data source's connection pool flush.
WebLogic Server determines the number of test failures before closing all connections based on the Test Frequency setting for the data source:
If Test Frequency is greater than 0, the number of test failures before closing all connections is set to 2.
If Test Frequency is set to 0 (periodic testing is disabled), the number of test failures before closing all connections is set to 25% of the Maximum Capacity for the data source.
If your DBMS becomes and remains unavailable, the data source will persistently test and try to replace dead connections while trying to satisfy connection requests. This behavior is beneficial because it enables the data source to react immediately when the database becomes available. However, testing a dead database connection can take as long as the network timeout, and can cause a long delay for clients.
To minimize this delay, the WebLogic data sources include logic that disables the data source after 2 consecutive failures to replace a dead connection. When an application requests a connection from a disabled data source, WebLogic Server throws a PoolDisabledSQLException immediately
to notify the client that a connection is not available.
For data sources that are disabled in this manner, WebLogic Server periodically runs a refresh process. The refresh process does the following:
The server instance executes a health check on the database server every 5 seconds. This setting is not configurable.
If the server instance recognizes that the database was recovered, it creates a new database connection and enables the data source.
You can also manually enable the data source using the Administration Console.
If your DBMS becomes and remains unavailable, the data source will persistently test and try to replace dead connections while trying to satisfy connection requests. This behavior is beneficial because it enables the data source to react immediately when the database becomes available. However, testing a dead database connection and trying futilely to replace it can in some cases take as long as the OS network timeout (minutes), and can cause long delays to clients before getting the expected failure message.
Note: If a data source is added to a multi data source, the multi data source takes over the responsibility of disabling and re-enabling its data sources. By default, a multi data source will check every two minutes (configurable) and re-enable any of its data sources that can re-establish connections. |
For some applications that use DBMS connections in a lot of very short cycles (such as reserve-do_one_query-close), the data source's testing of the connection can contribute a significant amount of overhead to each use cycle. To minimize the impact of connection testing, you can set the Seconds To Trust An Idle Pool Connection attribute in the JDBC data source configuration to trust recently-used or recently-tested database connections and skip the connection test.
If Test Reserved Connections is enabled on your data source, when an application requests a database connection, WebLogic Server tests the database connection before giving it to the application. If the request is made within the time specified for Seconds to Trust an Idle Pool Connection, since the connection was tested or successfully used by an application, WebLogic Server skips the connection test before delivering it to an application.
If Test Frequency is greater than 0 for your data source (periodic testing is enabled), WebLogic Server also skips the connection test if the connection was successfully used and returned to the data source within the time specified for Seconds to Trust an Idle Pool Connection.
For instructions to set Seconds to Trust an Idle Pool Connection, see "Configure testing options for a JDBC data source" in the Oracle WebLogic Server Administration Console Help.
Seconds to Trust an Idle Pool Connection 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.
You should set connection testing attributes so that they best fit your environment. For example, if your application cannot tolerate database connection failures, you should set Seconds to Trust an Idle Pool Connection to 0 and make sure Test Reserved Connections is enabled so that WebLogic Server will test every connection before giving it to an application. If your application is more sensitive to delays in getting a connection from the data source and can tolerate a possible application failure due to using a dead connection, you should set Seconds to Trust an Idle Pool Connection to a higher number, set Test Frequency to a lower number, and enable Test Reserved Connections.
With these settings, your application will rely more on the data source testing connections in the pool when they are not in use, rather than when an application requests a connection.
Note: Ultimately, even if WebLogic does its best, a connection may fail in the instant after WebLogic successfully tested it, and just before the application uses it. Therefore, every application should be written to respond appropriately in the case of unexpected exceptions from a dead connection. |
When you create a data source using the Administration Console, the Administration Console automatically sets the Test Table Name attribute for a data source based on the DBMS that you select. The Test Table Name attribute is used in connection testing which is optionally performed periodically or when you create or reserve a connection, depending on how you configure the testing options. For database tests to succeed, the database user used to create database connections in the data source must have access to the database table. If not, you should either grant access to the user (make this change in the DBMS) or change the Test Table Name attribute to the name of a table to which the user does have access (make this change in the WebLogic Server Administration Console).
The Test Table Name is an overloaded parameter. Its simplest form is to name a table that WLS will query to test a connection. Setting it to any table, such as "DUAL" for Oracle, will cause the data source to run the query select count(*) from DUAL
. If used in this mode, Oracle recommends that you choose a small, infrequently updated table (preferably a pseudo-table such as DUAL).
The second manner in which you can define this parameter is to allow any specific SQL string to be executed to test the connection. To use this option, set the parameter to "SQL " plus the desired sql string. For example SQL select 1
works for SQLServer, which does not need a table in queries to select constants. This option is useful for adding DBMS-side control of WLS pool connection testing, and to make the test as fast as possible.
Table 10-1 Default Test Table Name by DBMS
DBMS | Default Test Table Name (Query) |
---|---|
Adabas for z/OS |
SQL call shadow_adabas('select * from employees') |
Cloudscape |
SQL SELECT 1 |
DB2 |
SQL SELECT COUNT(*) FROM SYSIBM.SYSTABLES |
FirstSQL |
SQL SELECT 1 |
IMS/TM for z/OS |
SQL call shadow_ims('otm','/dis','cctl') |
Informix |
SQL SELECT COUNT(*) FROM SYSTABLES |
Microsoft SQL Server |
SQL SELECT 1 |
MySQL |
SQL SELECT 1 |
Oracle |
SQL SELECT 1 FROM DUAL |
PostgreSQL |
SQL SELECT 1 |
Progress |
SQL SELECT COUNT(*) FROM SYSTABLES |
Sybase |
SQL SELECT 1 |
WebLogic JDBC data sources include the Connection Creation Retry Frequency option (ConnectionCreationRetryFrequencySeconds
in the JDBCConnectionPoolParamsBean
) that you can use to specify the number of seconds between attempts to establish connections to the database. If set and if the database is unavailable when the data source is created, WebLogic Server attempts 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. This option applies to connections created when the data source is created at server startup or when the data source is deployed or if the initial capacity is increased. It does not apply to connections created for pool expansion or to replace a defunct connection in the pool.
By default, Connection Creation Retry Frequency is 0 seconds. When the value is set to 0, connection creation retries is disabled and data source creation fails if the database is unavailable.
See the JDBC Data Source: Configuration: Connection Pool page in the Administration Console or see "JDBCConnectionPoolParamsBean" in the Oracle WebLogic Server MBean Reference for more details about this option.
JDBC data sources have two attributes that you can set to enable connection requests to wait for a connection from a data source: Connection Reserve Timeout (ConnectionReserveTimeoutSeconds
) and Maximum Waiting for Connection (HighestNumWaiters
). You use these two attributes together to enable connection requests to wait for a connection without disabling your system by blocking too many threads.
See the JDBC Data Source: Configuration: Connection Pool page in the Administration Console or see "JDBCConnectionPoolParamsBean" in the Oracle WebLogic Server MBean Reference for more details about these options.
Also see "Enable connection requests to wait for a connection" in the Administration Console Online Help.
When an application requests a connection from a data source, if all connections in the data source are in use and if the data source has expanded to its maximum capacity, the application will get a Connection Unavailable SQL Exception. To avoid this, you can configure the Connection Reserve Timeout value (in seconds) so that connection requests will wait for a connection to become available. After the Connection Reserve Timeout has expired, if no connection becomes available, the request will fail and the application will get a PoolLimitSQLException
exception.
If you set Connection Reserve Timeout to -1
, a connection request will timeout immediately if there is no connection available. If you set Connection Reserve Timeout to 0
, a connection request will wait indefinitely. The default value is 10 seconds.
See "Enable connection requests to wait for a connection" in the Oracle WebLogic Server Administration Console Help.
Connection requests that wait for a connection block a thread. If too many connection requests concurrently wait for a connection and block threads, your system performance can degrade. To avoid this, you can set the Maximum Waiting for Connection (HighestNumWaiters
) attribute, which limits the number connection requests that can concurrently wait for a connection.
If you set Maximum Waiting for Connection (HighestNumWaiters
) to MAX-INT
(the default), there is effectively no bound on how many connection requests can wait for a connection. If you set Maximum Waiting for Connection to 0
, connection requests cannot wait for a connection. If the maximum number of requests has been met, a SQLException
is thrown when an application requests a connection.
A leaked connection is a connection that was not properly returned to the connection pool in the data source. To automatically recover leaked connections, you can specify a value for Inactive Connection Timeout
on the JDBC Data Source: Configuration: Connection Pool page in the Administration Console. When you set a value for Inactive Connection Timeout,
WebLogic Server forcibly returns a connection to the data source when there is no activity on a reserved connection for the number of seconds that you specify. When set to 0
(the default value), this feature is turned off.
See the JDBC Data Source: Configuration: Connection Pool page in the Administration Console or see "JDBCConnectionPoolParamsBean" in the Oracle WebLogic Server MBean Reference for more details about this option.
Note that the actual timeout could exceed the configured value for Inactive Connection Timeout. The internal data source maintenance thread runs every 5 seconds. When it reaches the Inactive Connection Timeout (for example 30 seconds), it checks for inactive connections. To avoid timing out a connection that was reserved just before the current check or just after the previous check, the server gives an inactive connection a "second chance." On the next check, if the connection is still inactive, the server times it out and forcibly returns it to the data source. On average, there could be a delay of 50% more than the configured value.
When your applications attempt to get a connection from a data source in which there are no available connections, the data source throws an exception stating that a connection is not available in the data source. To avoid this error, make sure your data source can expand to the size required to accommodate your peak load of connection requests. To increase the maximum number of connections available in the data source, increase the value for Maximum Capacity for the data source on the JDBC Data Source: Configuration: Connection Pool page in the Administration Console.
With the Statement Timeout option on a JDBC data source, you can limit the amount of time that a statement takes to execute on a database connection reserved from the data source. When you set a value for Statement Timeout, WebLogic Server passes the time specified to the JDBC driver using the java.sql.Statement.setQueryTimeout()
method. WebLogic Server will make the call, and if the driver throws an exception, the value will be ignored. In some cases, the driver may silently not support the call, or may document limited support. Oracle recommends that you check the driver documentation to verify the expected behavior.
When Statement Timeout is set to -1, (the default) statements do not timeout.
See the JDBC Data Source: Configuration: Connection Pool page in the Administration Console or see "JDBCConnectionPoolParamsBean" in the Oracle WebLogic Server MBean Reference for more details about this option.
To minimize the time it takes for an application to reserve a database connection from a data source and to eliminate contention between threads for a database connection, you can add the Pinned-To-Thread
property in the connection Properties list for the data source, and set its value to true
.
When Pinned-To-Thread
is enabled, WebLogic Server pins a database connection from the data source 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 data source, WebLogic Server keeps the connection with the execute thread and does not return it to the data source. When an application subsequently requests a connection using the same execute thread, WebLogic Server provides the connection already reserved by the thread. There is no locking contention on the data source 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.
Note: In this release, the Pinned-To-Thread feature does not work with multi data sources, Oracle RAC, and IdentityPool. These features rely on the ability to return a connection to the connection pool and reacquire it if there is a connection failure or connection identity does not match. |
See "JDBC Data Source: Configuration: Connection Pool" in the Oracle WebLogic Server Administration Console Help.
Because the nature of connection pooling behavior is changed when PinnedToThread
is enabled, some connection pool attributes or features behave differently or are disabled to suit the behavior change:
Maximum Capacity is ignored. The number of connections in a connection pool equals the greater of either the initial capacity or the number of connections reserved from the connection pool.
Shrinking does not apply to connection pools with PinnedToThread
enabled because connections are never returned to the connection pool. Effectively, they are always reserved.
When you Reset a connection pool, the reset connections from the connection pool are marked as Test Needed. The next time each connection is reserved, WebLogic Server tests the connection and recreates it if necessary. Connections are not tested synchronously when you reset the connection pool. This feature requires that Test Connections on Reserve is enabled and a Test Table Name or query is specified.
When PinnedToThread
is enabled, the maximum capacity of the connection pool (maximum number of database connections created in the connection pool) becomes the number of execute threads used to request a connection multiplied by the number of concurrent connections each thread reserves. This may exceed the Maximum Capacity specified for the connection pool. You may need to consider this larger number of connections in your system design and ensure that your database allows for additional associated resources, such as open cursors.
Also note that connections are never returned to the connection pool, which means that the connection pool can never shrink to reduce the number of connections and associated resources in use. You can minimize this cost by setting an additional driver parameter onePinnedConnectionOnly
. When onePinnedConnectionOnly
=true
, only the first connection requested is pinned to the thread. Any additional connections required by the thread are taken from and returned to the connection pool as needed. Set onePinnedConnectionOnly
using the Properties
attribute, for example:
Properties="PinnedToThread=true;onePinnedConnectionOnly=true;user=examples"
If your system can handle the additional resource requirements, Oracle recommends that you use the PinnedToThread
option to increase performance.
If your system cannot handle the additional resource requirements or if you see database resource errors after enabling PinnedToThread
, Oracle recommends not using PinnedToThread
.
Some JDBC objects from a driver that are returned from WebLogic Server are wrapped by default. Wrapping data source objects provides WebLogic Server the ability to:
Generate debugging output from all method calls.
Track connection utilization so that connections can be timed out appropriately.
Provide transparent automatic transaction enlistment and security authorization.
WebLogic Server provides the ability to disable wrapping which provides the following benefits:
Although WebLogic Server generates a dynamic proxy for vendor methods that implement an interface to show through the wrapper, some data types do not implement an interface. For example, Oracle data types Array, Blob, Clob, NClob, Ref, SQLXML, and Struct are classes that do not implement interfaces. Disabling wrapping allows applications to use native driver objects directly.
Eliminating wrapping overhead can provide a significant performance improvement.
When wrapping is disabled (the wrap-types
element is false
), the following data types are not wrapped:
Array
Blob
Clob
NClob
Ref
SQLXML
Struct
ParameterMetaData
No connection testing performed.
ResultSetMetaData
No connection testing performed.
No result set testing performed.
No JDBC MT profiling performed.
You can use the Administration Console and WLST to disable data type wrapping.
To disable wrapping of JDBC data type objects:
If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.
In the Domain Structure tree, expand Services, then select Data Sources.
On the Summary of Data Sources page, click the data source name.
Select the Configuration: Connection Pool tab.
Scroll down and click Advanced to show the advanced connection pool options.
In Wrap Data Types, deselect the checkbox to disable wrapping.
Click Save.
To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
This change does not take effect immediately—it requires that the data source be redeployed or the server be restarted.
The following is a WLST code snippet to disable data type wrapping:
. . . jdbcSR = create(dsname,"JDBCSystemResource"); theJDBCResource = jdbcSR.getJDBCResource(); poolParams = theJDBCResource.getJDBCConnectionPoolParams(); poolParams.setWrapTypes(false); . . .
This change does not take effect immediately—it requires that the data source be redeployed or the server be restarted.
This chapter provides information on how to use WebLogic server with Oracle Fast Connection Failover.
WebLogic Server supports Fast Connection Failover, an Oracle feature which provides an application-independent method to implement Oracle RAC event notifications, such as detection and cleanup of invalid connections, load balancing of available connections, and work redistribution on active Oracle RAC instances.
For more information, see "Fast Connection Failover" at http://download-east.oracle.com/docs/cd/B19306_01/java.102/b14355/fstconfo.htm#CIHJBFFC in the Oracle® Database JDBC Developer's Guide and Reference.
To enable Fast Connection Failover on a data source, set the following connection pool properties:
In Driver Class Name—set the class name to oracle.jdbc.pool.OracleDataSource
.
In Properties—set the ONS configuration string to remotely subscribe the Oracle RAC nodes to Oracle FAN/ONS events. For example: ONSConfiguration=nodes=hostname1:port1,hostname2:port2
Note: Oracle's OracleDataSource class is not XA-capable, so the resulting data source does not implement a XA connection pool. |
Because the Oracle driver uses ONS to implement Fast Connection Failover, you must add ons.jar
to the WebLogic classpath
. To do so, edit the setDomainEnv
script in the domain's bin
directory, and add ons.jar
to the POST_CLASSPATH
variable.
Configuring and Managing JDBC Data Sources for Oracle WebLogic Server
11g Release 1 (10.3.6)
E13737-11
April 2014
This document provides JDBC data source configuration and administration information.
Oracle Fusion Middleware Configuring and Managing JDBC Data Sources for Oracle WebLogic Server, 11g Release 1 (10.3.6)
E13737-11
Copyright © 2007, 2014, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.
This chapter provides advanced configuration options that can provide improved data source and driver performance when using Oracle drivers and databases. Options include proxy authentication, setting credentials on a connection, connection harvesting, and labeling connections.
WebLogic Server provides several attributes that provide improved Data Source performance when using Oracle drivers, including:
Oracle Enable JavaNet Fastpath: Enables the Oracle JDBC JavaNet Fastpath to reduce data copies and fragmentation.
Oracle Optimize UTF8 Conversion: Enables the Oracle JDBC optimize UTF-8 conversion option.
If your environment supports these attributes, see Configure Oracle parameters in the Oracle WebLogic Server Administration Console Help.
Proxy authentication allows one JDBC connection to act as a proxy for other JDBC connections to an Oracle database. You can configure a WebLogic data source to allow a client to connect to a database through an application server as a proxy user. The client authenticates with the application server and the application server authenticates with the Oracle database. This allows the client's user name to be maintained on the connection with the database.
Use the following steps to configure proxy authentication to an Oracle database:
If you have not yet done so, create the necessary WebLogic Server and database users.
On the Oracle database, provide CONNECT THROUGH
privileges.
For example:
SQL> ALTER USER wlsuser
GRANT CONNECT THROUGH dbuser
;
where wlsuser
is a WebLogic Server user and dbuser
is an Oracle database user.
On a WebLogic Server instance:
Create a generic or GridLink data source and set the user to the value of dbuser
.
Map the value of wlsuser
to the value of dbuser
. See "Configure credential mapping for a JDBC data source"" in the Oracle WebLogic Server Administration Console Help.
Redeploy the data source.
Log on to a WebLogic Server instance using the value of wlsuser
.
Enable Proxy Authentication, see "Configure Oracle parameters" in Oracle WebLogic Server Administration Console Help.
A proxy session is opened on the connection for the application-authenticated user each time a connection request is made on the pool. The proxy session is closed when the connection is returned to the pool.
Note: Opening or closing a proxy session:
These behaviors may impact applications that share a connection across instances and expect some state to be associated with the connection. |
You can configure a WebLogic data source to allow a connection to set database credentials when connecting to an Oracle database. When configured, a proxy session is opened for a connection created using getConnection(username, password)
to specify a database user and password. This provides a simple, light-weight mechanism to authenticate many users and avoids the need to credential mapping entries for each database user.
Use the following steps to configure proxy authentication of database credentials set on a connection to an Oracle database:
If you have not yet done so, create the necessary database users.
On the Oracle database, provide CONNECT THROUGH
privileges.
For example:
SQL> ALTER USER connectionuser
GRANT CONNECT THROUGH dbuser
;
where connectionuser
is the name of the application user to be authenticated and dbuser
is an Oracle database user.
On a WebLogic Server instance, create a generic or GridLink data source and set the user to the value of dbuser
.
Enable Use Database Credentials, see "Configure Oracle parameters" in Oracle WebLogic Server Administration Console Help.
A proxy session is opened on the connection for the application-authenticated user each time a connection request is made on the pool. The proxy session is closed when the connection is returned to the pool.
Note: Opening or closing a proxy session:
These behaviors may impact applications that share a connection across instances and expect some state to be associated with the connection. |
Open a connection using getConnection(username, password)
.
Note:
|
Consider the following when setting database credentials on a connection that participates in transactions:
When using getConnection(username, password)
with data sources configured with non-XA LLR or 1PC (JTS driver) with global transactions, the first connection obtained within the transaction is returned on subsequent getConnection()
requests regardless of the values of username
/password
specified. The connection must use the proxy user session information from the first getConnection()
request because the connection must be shared among all users of the connection when using LLR or 1PC.
For XA data sources, connections may be stored with the transaction context on a given JVM and subsequent getConnection()
requests may return a connection with a proxy user for a prior getConnection()
request. Oracle recommends that a single database username
be specified when using this feature in global transactions.
You can specify a number of reserved connections to be released when a data source reaches a specified number of available connections. Harvesting helps to ensure that a specified number of connections are always available in the pool and improves performance by minimizing connection initialization.
Connection harvesting is particularly useful if an application caches connection handles. Caching is typically performed for performance reasons because it minimizes the initialization of state necessary for connections to participate in a transaction. For example: A connection is reserved from the data source, initialized with necessary session state, and then held in a context object. Holding connections in this manner may cause the connection pool to run out of available connections. Connection harvesting appropriately reclaims the reserved connections and allows the connections to be reused.
Use the following steps to use connection harvesting in your applications:
The Connection Harvest Trigger Count
attribute of a data source configuration is used to enable and specify a threshold to trigger connection harvesting. For example, if Connection Harvest Trigger Count
is set to 10, connection harvesting is enabled and the data source begins to harvest reserved connections when the number of available connections drops to 10. A value of -1 indicates that connection harvesting is disabled.
When connection harvesting is triggered, the Connection Harvest Max Count
specifies how many reserved connections can be returned to the pool. The number of connections actually harvested ranges from 1 to the value of Connection Harvest Max Count
.
See "Configure connection harvesting for a connection pool" in Oracle WebLogic Server Administration Console Help.
When connection harvesting is enabled, all connections are harvestable. If you do not want a connection to be harvestable, you must explicitly mark it as unharvestable by calling the setConnectionHarvestable(
boolean
)
method in the oracle.ucp.jdbc.HarvestableConnection
interface with false
as the argument value.
For example, use the following statements to prevent harvesting when a transaction is used within a transaction:
. . . Connection conn = datasource.getConnection(); ((HarvestableConnection) conn).setConnectionHarvestable(false); . . .
After the transaction completes, you can mark the connection as harvestable by setting setConnectionHarvestable(true)
so the connection can be harvested if required. You can tell the harvestable status of a connection by calling isConnectionHarvestable()
.
When a connection is harvested, an application callback is executed to cleanup the connection if the callback has been registered. A unique callback must be generated for each connection; generally it needs to be initialized with the connection object. For example:
import java.sql.Connection; . . . public myHarvestingCallback implements ConnectionHarvestingCallback { private Connection conn; mycallback(Connection conn) { this.conn = conn; } public boolean cleanup() { try { conn.close(); } catch (Exception ignore) { return false; } return true; } } . . . Connection conn = ds.getConnection(); try { (HarvestableConnection)conn).registerConnectionHarvestingCallback( new myHarvestingCallback(conn)); (HarvestableConnection)conn).setConnectionHarvestable(true); } catch (Exception exception) { // This can't be from registration – setConnectionHarvestable must have failed. // That most likely means that the connection has already been harvested. // Do whatever logic is necessary to clean up here and start over. throw new Exception(”Need to get a new connection”); } . . .
Note: Consider the following:
|
Applications often initialize connections retrieved from a connection pool before using the connection. The initialization varies and could include simple state re-initialization that requires method calls within the application code or database operations that require round trips over the network. The cost of such initialization may be significant.
Labeling connections allows an application to attach arbitrary name/value pairs to a connection. The application can request a connection with the desired label from the connection pool. By associating particular labels with particular connection states, an application can retrieve an already initialized connection from the pool and avoid the time and cost of re-initialization. The connection labeling feature does not impose any meaning on user-defined keys or values; the meaning of user-defined keys and values is defined solely by the application.
Some of the examples for connection labeling include, role, NLS language settings, transaction isolation levels, stored procedure calls, or any other state initialization that is expensive and necessary on the connection before work can be executed by the resource.
Connection labeling is application-driven and requires the following:
The oracle.ucp.jdbc.LabelableConnection
interface is used to apply and remove connection labels, as well as retrieve labels that have been set on a connection.
The oracle.ucp.ConnectionLabelingCallback
interface is used to create a labeling callback that determines whether or not a connection with a requested label already exists. If no connections exist, the interface allows current connections to be configured as required.
Configuring the data source to keep connections after transactions, see "JDBC Data Source: Configuration: Transaction" in Oracle WebLogic Server Administration Console Help.
A labeling callback is used to define how the connection pool selects labeled connections and allows the selected connection to be configured before returning it to an application. Applications that use the connection labeling feature must provide a callback implementation.
A labeling callback is used when a labeled connection is requested but there are no connections in the pool that match the requested labels. The callback determines which connection requires the least amount of work in order to be re-configured to match the requested label and then allows the connection's labels to be updated before returning the connection to the application.
Note: Connection Labeling is not supported from client applications that use RMI. See "Using the WebLogic RMI Driver (Deprecated)" in Programming JDBC for Oracle WebLogic Server. |
To create a labeling callback, an application implements the oracle.ucp.ConnectionLabelingCallback
interface. One callback is created per connection pool. The interface provides two methods as shown below:
public int cost(Properties requestedLabels, Properties currentLabels);
public boolean configure(Properties requestedLabels, Connection conn);
The connection pool iterates over each connection available in the pool. For each connection, it calls the cost
method. The result of the cost
method is an integer which represents an estimate of the cost required to reconfigure the connection to the required state. The larger the value, the costlier it is to reconfigure the connection. The connection pool always returns connections with the lowest cost value. The algorithm is as follows:
If the cost method returns 0 for a connection, the connection is a match (note that this does not guarantee that requestedLabels
equals currentLabels
). The connection pool does not call configure on the connection found and simply returns the connection.
If the cost method returns a value that is not 0 (a negative or positive integer), then the connection pool iterates until it finds a connection with a cost value of 0 or runs out of available connections.
If the pool has iterated through all available connections and the lowest cost of a connection is Integer.MAX_VALUE
(2147483647 by default), then no connection in the pool is able to satisfy the connection request. The pool creates a new connection, calls the configure
method on it, and then returns this new connection. If the pool has reached the maximum pool size (it cannot create a new connection), then the pool either throws an SQL exception or waits if the connection wait timeout attribute is specified.
If the pool has iterated through all available connections and the lowest cost of a connection is less than Integer.MAX_VALUE
, then the configure method is called on the connection and the connection is returned. If multiple connections are less than Integer.MAX_VALUE
, the connection with the lowest cost is returned.
There is also an extended callback interface oracle.ucp.jdbc.ConnectionLabelingCallback
that has an additional getRequestLabels()
method. getRequestedLabels
is invoked at getConnection()
time when no requested labels are provided and there is an instance registered. This occurs when the standard java.sql.Datasource
getConnection()
methods are used that do not provide the label information on the getConnection()
call.
The following code example demonstrates a simple labeling callback implementation that implements both the cost
and configure
methods. The callback is used to find a labeled connection that is initialized with a specific transaction isolation level.
Example 6-1 Labeling Callback
import oracle.ucp.jdbc.ConnectionLabelingCallback; import oracle.ucp.jdbc.LabelableConnection; import java.util.Properties; import java.util.Map; import java.util.Set; import weblogic.jdbc.extensions.WLDataSource; class MyConnectionLabelingCallback implements ConnectionLabelingCallback { public MyConnectionLabelingCallback() { } public int cost(Properties reqLabels, Properties currentLabels) { // Case 1: exact match if (reqLabels.equals(currentLabels)) { System.out.println("## Exact match found!! ##"); return 0; } // Case 2: some labels match with no unmatched labels String iso1 = (String) reqLabels.get("TRANSACTION_ISOLATION"); String iso2 = (String) currentLabels.get("TRANSACTION_ISOLATION"); boolean match = (iso1 != null && iso2 != null && iso1.equalsIgnoreCase(iso2)); Set rKeys = reqLabels.keySet(); Set cKeys = currentLabels.keySet(); if (match && rKeys.containsAll(cKeys)) { System.out.println("## Partial match found!! ##"); return 10; } // No label matches to application's preference. // Do not choose this connection. System.out.println("## No match found!! ##"); return Integer.MAX_VALUE; } public boolean configure(Properties reqLabels, Object conn) { try { String isoStr = (String) reqLabels.get("TRANSACTION_ISOLATION"); ((Connection)conn).setTransactionIsolation(Integer.valueOf(isoStr)); LabelableConnection lconn = (LabelableConnection) conn; // Find the unmatched labels on this connection Properties unmatchedLabels = lconn.getUnmatchedConnectionLabels(reqLabels); // Apply each label <key,value> in unmatchedLabels to conn for (Map.Entry<Object, Object> label : unmatchedLabels.entrySet()) { String key = (String) label.getKey(); String value = (String) label.getValue(); lconn.applyConnectionLabel(key, value); } } catch (Exception exc) { return false; } return true; } public java.util.Properties getRequestedLabels() { Properties props = new Properties(); // Set based on some application state that might be on a thread-local, http session info, etc. String value = ”value”; props.put("TRANSACTION_ISOLATION”, value); return props; } }
A WLS data source provides the registerConnectionLabelingCallback(ConnectionLabelingCallback callback)
method for registering labeling callbacks. Only one callback may be registered on a connection pool. The following code example demonstrates registering a labeling callback that is implemented in the MyConnectionLabelingCallback
class:
. . . import weblogic.jdbc.extensions.WLDataSource; . . . MyConnectionLabelingCallback callback = new MyConnectionLabelingCallback(); ((WLDataSource)ds).registerConnectionLabelingCallback( callback ); . . .
You can also register the callback using the Administration Console, see "Configure a connection labeling callback class" in Oracle WebLogic Server Administration Console Help.
You can remove a labeling callback by using one of the following methods:
If you have programatically set a callback, use the removeConnectionLabelingCallback()
method as shown in the following example:
. . . import weblogic.jdbc.extensions.WLDataSource; . . . ((WLDataSource)ds).removeConnectionLabelingCallback( callback ); . . .
If you have administratively configured the callback, remove the callback from the data source configuration. See "Configure a connection labeling callback class" in Oracle WebLogic Server Administration Console Help
Note: An application must use one of the methods to register and remove callbacks but not both. For example, if you register the callback on a connection using |
Labels are applied on a reserved connection using the applyConnectionLabel
method from the LabelableConnection
interface. Any number of connection labels may be cumulatively applied on a reserved connection. Each time a label is applied to a connection, the supplied key/value pair is added to the existing collection of labels. Only the last applied value is retained for any given key.
Note: A labeling callback must be registered on the connection pool before a label can be applied on a reserved connection; otherwise, labeling is ignored. See Creating a Labeling Callback. |
The following example demonstrates initializing a connection with a transaction isolation level and then applying a label to the connection:
. . . String pname = "property1"; String pvalue = "value"; Connection conn = ds.getConnection(); // initialize the connection as required. conn.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE); ((LabelableConnection) conn).applyConnectionLabel(pname, pvalue); . . .
A WLS data source provides two getConnection
methods that are used to reserve a labeled connection from the pool. The methods are shown below:
public Connection getConnection(java.util.Properties labels) throws SQLException;
public Connection getConnection(String user, String password, java.util.Properties labels) throws SQLException;
The methods require that the label be passed to the getConnection
method as a Properties
object. The following example demonstrates getting a connection with the label property1 value.
. . . import weblogic.jdbc.extensions.WLDataSource; . . . String pname = "property1"; String pvalue = "value"; Properties label = new Properties(); label.setProperty(pname, pvalue); . . . Connection conn = ((WLDataSource)ds).getConnection(label); . . .
It is also possible to use the standard java.sql.Datasource getConnection()
methods. In this case, the label information is not provided on the getConnection()
call. The interface oracle.ucp.jdbc.ConnectionLabelingCallback
is used:
java.util.Properties getRequestedLabels();
getRequestedLabels
is invoked at getConnection()
time when no requested labels are provided and there is an instance registered.
A connection may have multiple labels that each uniquely identifies the connection based on some desired criteria. The getUnmatchedConnectionLabels
method is used to verify which connection labels matched from the requested labels and which did not. The method is used after a connection with multiple labels is reserved from the connection pool and is typically used by a labeling callback. The following code example demonstrates checking for unmatched labels:
. . . String pname = "property1"; String pvalue = "value"; Properties label = new Properties(); label.setProperty(pname, pvalue); . . . Connecion conn = ((WLDataSource)ds).getConnection(label); Properties unmatched = ((LabelableConnection)connection).getUnmatchedConnectionLabels (label); . . .
The removeConnectionLabel
method is used to remove a label from a connection. This method is used after a labeled connection is reserved from the connection pool. The following code example demonstrates removing a connection label:
. . . String pname = "property1"; String pvalue = "value"; Properties label = new Properties(); label.setProperty(pname, pvalue); Connection conn = ((WLDataSource)ds).getConnection(label); . . . ((LabelableConnection) conn).removeConnectionLabel(pname); . . .
Copyright © 1994-2016, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.
If this document is in preproduction status:
This documentation is in preproduction status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.
If this document is in private preproduction status:
The information contained in this document is for informational sharing purposes only and should be considered in your capacity as a customer advisory board member or pursuant to your beta trial agreement only. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described in this document remains at the sole discretion of Oracle.
This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle Master Agreement, Oracle License and Services Agreement, Oracle PartnerNetwork Agreement, Oracle distribution agreement, or other license agreement which has been executed by you and Oracle and with which you agree to comply. This document and information contained herein may not be disclosed, copied, reproduced, or distributed to anyone outside Oracle without prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc
.
Access to Oracle Support
Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info
or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs
if you are hearing impaired.