Pooled Connection Limitation Getting a Connection from an Application-Scoped Data Source

Using WebLogic JDBC in an Application 2-3

2.1.3 Possible Exceptions When a Connection Request Fails

The weblogic.jdbc.extensions package includes the following exceptions that can be thrown when an application request fails. Each exception extends java.sql.SQLException . ■ ConnectionDeadSQLException —generated when an application request to get a connection fails because the connection test on the reserved connection failed. This typically happens when the database server is unavailable. ■ ConnectionUnavailableSQLException —generated when an application request to get a connection fails because there are currently no connections available in the pool to be allocated. This is a transient failure, and is generated if all connections in the pool are currently in use. It can also be thrown when connections are unavailable because they are being tested. ■ PoolDisabledSQLException —generated when an application request to get a connection fails because the JDBC Data Source has been administratively disabled. ■ PoolLimitSQLException —generated when an application request to get a connection fails due to a configured threshold of the data source, such as HighestNumWaiters , ConnectionReserveTimeoutSeconds, and so forth. ■ PoolPermissionsSQLException —generated when an application request to get a connection fails a security authentication or authorization check.

2.2 Pooled Connection Limitation

When using pooled connections in a data source, it is possible to execute DBMS-specific SQL code that will alter the database connection properties and that WebLogic Server and the JDBC driver will be unaware of. When the connection is returned to the data source, the characteristics of the connection may not be set back to a valid state. For example, with a Sybase DBMS, if you use a statement such as set rowcount 3 select from y , the connection will only ever return a maximum of 3 rows from any subsequent query on this connection. When the connection is returned to the data source and then reused, the next user of the connection will still only get 3 rows returned, even if the table being selected from has 500 rows. In most cases, there is standard JDBC code that can accomplish the same result. In this example, you could use setMaxRows instead of set rowcount. Oracle recommends that you use the standard JDBC code instead of the DBMS-specific SQL code. When you use standard JDBC calls to alter the connection, Weblogic Server returns the connection to a standard state when the connection is returned to the data source. If you use DBMS-specific SQL code that alters the connection, you must set the connection back to an acceptable state before returning the connection to the data source. Note: The code above uses one of several available procedures for obtaining a JNDI context. For more information on JNDI, see Programming JNDI for Oracle WebLogic Server. 2-4 Oracle Fusion Middleware Programming JDBC for Oracle WebLogic Server

2.3 Getting a Connection from an Application-Scoped Data Source

To get a connection from an application-scoped data source, see Getting a Database Connection from a Packaged JDBC Module in Configuring and Managing JDBC Data Sources for Oracle WebLogic Server. 3 Performance Tuning Your JDBC Application 3-1 3 Performance Tuning Your JDBC Application The following sections explain how to get the best performance from JDBC applications: ■ Section 3.1, WebLogic Performance-Enhancing Features