Best of Breed JDBC Drivers for J2EE Web Services and GRID

Best of Breed JDBC Drivers for J2EE Web Services and GRID An Oracle White Paper December 2003

Best of Breed JDBC Drivers for J2EE, WebServices, and GRID

Executive Overview.............................................................................. 4 Introduction........................................................................................... 4 new JDBC features overview................................................................ 5

Re-Architecture Groundwork ........................................................... 5 Unified Drivers Code Base ........................................................... 5 Best performing JDBC drivers - Faster JDBC Application execution....................................................................................... 5

Best Database Connectivity for Java, J2EE, Web Services and GRID Services .................................................................................. 5

Comprehensive JDBC 3.0 support................................................ 5 Best Database Connectivity for Web Services and GRID Services6

Best integrated Drivers with The Oracle Database........................... 7 Manageability / Ease of Use / Flexibility ..................................... 7 New and Enhanced Database Type support ................................. 7

Compatible type-2 and type-4 JDBC drivers.................................... 8 Miscellaneous ................................................................................... 8

Implicit Connection Cache ................................................................... 9 Transparent access to the Connection Cache.................................... 9 Support for Any User-Authenticated Connection .......................... 10 Connection Retrieval based on User defined Attributes................. 10 Applying Connection Attributes to a Cached Connection.............. 11 Connection Cache Properties.......................................................... 12 Abandoned Connection Timeout Support ...................................... 12 Statement Caching Support ............................................................ 13 Connection Cache Manager............................................................ 13 Connection Recycling Support ....................................................... 14 Dynamic Reconfiguration Support ................................................. 14 Monitoring the Connection Cache.................................................. 15 Connection Retrieval Based on Attributes and Weights ................ 15 Multi-cache Support ....................................................................... 17

Fast Connection Fail-Over.................................................................. 17 Enabling Fast Connection Fail-over ............................................... 18 RAC DOWN/UP Event Processing ................................................ 18 Runtime Work-Request Distribution .............................................. 19


Handling of In-Flight Transactions................................................. 20 Fast Connection Fail-over and TAF ............................................... 20

Conclusion .......................................................................................... 20



EXECUTIVE OVERVIEW For faster Java/J2EE applications development, Oracle Database 10g JDBC offers: (i) a comprehensive support for JDBC 3.0 APIs including Named Parameters, DATALINK datatype and the REF interface, J2EE Connector Architecture Resource Adapters, and an early implementation of JDBC 3.0 Web RowSet (JSR-114) draft specification; (ii) a comprehensive set of features allowing customers to fully utilize the features offered by the Oracle Database 10g including INTERVAL DAY TO SECOND type support, new IEEE native database types support, unlimited LOB size, VARRAY enhancements, and LONG-to-LOB conversions, proxy authentication, advanced encryption algorithms, binding variables by names, “Implicit Connection Cache”, and RAC/HA “Fast Connection Fail-Over”. For faster Java/J2EE applications execution, following a complete re-architecture effort, 10g JDBC offers best performance, including direct XA for distributed transactions. For simplified JDBC applications deployment, news hassle-free OCI drivers install, hassle-free upgrade, easy migration, and greater compatibility with different versions of Oracle databases. Finally, reducing the functional gap between type-2 and type-4 JDBC drivers -- including support PL/SQL index tables, passing, retrieving, and registering parameters by name, and support for RAC/HA -- allows flexibility of using different flavor of JDBC drivers for development and deployment.

INTRODUCTION JDBC provides database connectivity, either explicitly or under the covers, to plain old Java objects (a.k.a. POJO), as well as J2SE applications, J2EE components, Web services, ERP packages, O/R Mapping frameworks, and GRID Services. Oracle Database 10g JDBC aimed at delivering the best of breed, fast, efficient, reliable, highly available, most J2EE/JDBC compatible, Web-services-enabled and grid-enabled drivers. The first part of this paper gives an overview of the new features, including common re-architecture groundwork for all driver types; major performance enhancements; comprehensive support for standard JDBC 3.0 features; improved manageability and ease-of-use, tracing; functionally compatible type-2 and type-4 drivers; new database types and enhanced support for LOB and VARRAY; support for draft JDBC Web


RowSet (JSR-114) for Web services; new Implicit Connection Cache and Fast Connection Fail-over; and touch on upcoming Transparent Session Migration for Grid computing. The second part describes in greater detail, the new, Implicit Connection Cache, which furnishes a transparent mechanism for using and managing data sources connections caches, eliminating the complexity/confusion involved in using and pooling data sources and the Fast Connection Fail-Over, which, coupled with the RAC event notification mechanism provides an early data source connection failure detection and faster fail-over.

NEW JDBC FEATURES OVERVIEW

Re-Architecture Groundwork

Unified Drivers Code Base

Since Oracle8i, the Oracle JDBC development and performance organizations have been intensely evaluating the Oracle JDBC drivers, with the following goals: a single, unified code base for all drivers and delivering the best performance. Unifying the code base for all driver types including the type-2 client, the type-2 server, the type-4 client and the type-4 server will allow faster and common implementation of new features within a single base code, resulting in the reduction of -- if not eliminating -- the functional gap across drivers.

Best performing JDBC drivers - Faster JDBC Application execution

Performance is the second major goal of the re-architecture groundwork. In order to deliver the best performing drivers -- faster SQL/XML data query/retrieval, best performing custom Java/J2SE/J2EE applications as well as best standards SPECJApp200x benchmarks results -- we have: monitored and improved the code path length, that is the number of machine instructions executed; minimized the number of Java methods called to satisfy a request through algorithms that eliminate the creation of many Java intermediate and temporary objects, while caching and reusing as many as possible; we also have minimized data movement to/from database; and optimized Java/SQL data conversion operations. In addition, new features such as the support for native IEEE Double and Float and the optimization of XA handling will also result in improved performance.

Best Database Connectivity for Java, J2EE, Web Services and GRID Services

Comprehensive JDBC 3.0 support

JDBC 3.0 support started with Oracle9i Release 2 JDBC drivers with: transaction savepoints, toggling between local and global transaction, reuse of PreparedStatement, and JDK 1.4.x support for client JDBC drivers.


In Oracle Database 10g, JDBC drivers offer the following new JDBC 3.0 features:

Named Parameters: this release supports named parameters in CallableStatement and PreparedStatement, which enable JDBC applications to pass parameters by name as well as registering, and retrieving output parameters by name. Under the covers, JDBC drivers first collect and store the information from the all setting input parameters by name (and also all the registering output parameters by name); then rewrite calls; and do all the setting (and registering) by ordinal just before the execution.

New Ref interface and Datalink/URL: a DATALINK value references a file outside of the underlying data source that the data source manages. The JDBC 3.0 specification maps this new JDBC data type to the Java type java.net.URL; and adds a new type code in java.sql.Types

J2EE Connector Architecture Resource Adapter: the new package oracle.jdbc.connector implements the service provider interface contracts of the J2EE Connector specification javax.resource.spi. The Oracle JDBC driver can function as a standard J2EE resource adapter for Oracle databases; enabling improved plug-ability; packaging and deployment.

Best Database Connectivity for Web Services and GRID Services

Figure 1 JDBC RowSet APIs

JDBC Web RowSet (JSR-114): this early implementation of JSR-114 (Public Draft), allows disconnected applications such as Web Services clients or J2EE


components to fetch a collection of rows from database tables (or other data sources) in XML format -- RowSet outputted as an XML document -- in a way such that no active connections is maintained with the data source and to scroll through, update locally, and synchronize the rows back to the data source.

Transparent Session Migration: for the near future, JDBC drivers will expose to Java applications, the ability to migrate stateless and stateful database sessions in Oracle RAC and GRID databases environment.

Best integrated Drivers with The Oracle Database This release also delivers a comprehensive set of features including manageability, ease of use, flexibility, new data types, and enhancements to LOB and VARRAY that allow customers to fully access the Oracle database functionality.

Manageability / Ease of Use / Flexibility

End-to-end tracing: JDBC drivers to propagate the middle-tier Web client id to the RDBMS engine so as to trace resource consumption from a Web Browser to the SQL corresponding operations.

Instant Client OCI driver: new packaging allows a downloadable, simplified, hassle-free, and “homeless”install of the type-2 “OCI” driver.

Enhanced Oracle JDBC Datum support: the separation of datum classes from the rest of jdbc for "small" download size for datum users. Better (finer-grain) exceptions rather than SQLException everywhere. Conversion and arithmetic operations methods on datum to-and-from other datum. This feature will provide JDBC applications using oracle.sql Datum with smaller download size; new datum conversion and arithmetic operations and finer-grain exception handling.

New and Enhanced Database Type support

The following enhancements or new datatypes increase the integration of the JDBC drivers with the Oracle database, resulting in faster application development and execution.

Native IEEE DOUBLE and Native IEEE Float: the new SQL floating-point number datatypes are supported in JDBC, allowing Java and J2EE applications using JDBC to perform faster arithmetic calculations without loss of information and with reduced storage. In order to bind a float or double to a binary_float or binary_double input parameter, cast the prepared statement to oracle.jdbc.driver.OraclePreparedStatement and invoke setBFloat() or SetBDouble(). If you instead invoke setFloat() or setDouble(), the actual data bind will be done as for a NUMBER column and there will be both loss of performance and possible data corruption. No such limitation exists for out binds for CallableStatements or for data recovered from result sets. binary_float and binary_double are not


supported as parameters for Java stored procedures and generally in the server-side internal driver.

Enhanced VARRAY support: the addition of aggregation functions (frequent item set counting); using collections for in-lists; general set operations -- intersect; union; member; equality; etc -- particularly useful for data mining applications.

LONG-to-LOB conversion: the addition of conversions functions for CLOBs and BLOB so that they are compatible with LONG; RAW and LONG RAW, simplifying their manipulation in JDBC applications and improve JDBC applications portability.

Unlimited size LOB: this feature removes the four Gigabyte length restriction for LOBs; JDBC Applications can now store/retrieve binary data bigger than the current four Gigabyte limit.

INTERVAL DAY TO SECOND: JDBC applications can now use the database’s INTERVAL DAY TO SECOND datatype for improved time management.

Compatible type-2 and type-4 JDBC drivers The following internal enhancements and features allow the flexibility of using either type-2 “OCI” or type-4 “thin” JDBC drivers for development and deployment:

PL/SQL Index table: this feature lets you send and receive PL/SQL tables in the type-4 “thin” JDBC driver. Using setPlsqlIndexTable() and getOraclePlsqlIndexT you can exchange Java collections with PL/SQL collections.

New encryption algorithms: the type-4 “thin” JDBC driver now supports 3DES112 and 3DES168 as values for the connection property SQLNET.ENCRYPTION_TYPES_CLIENT in the JDBC Thin driver.

Direct XA: performance optimization of JDBC XA operations when using the type-4 “thin” JDBC driver.

Proxy authentication: the type-4-“thin” JDBC driver now offers the ability for multiple middle-tier users/threads to share a single database connection under the same authenticated user.

RAC/HA Fail-Over: both type-4 “thin” and type-2 “OCI” now offers compatible support for RAC. See part-II for more details on Fast Connection Fail-Over

Miscellaneous Stop shipping classes111 and zip files: following J2SE 1.1.x JDK de-support by Sun Microsystems, starting from this release, JDBC classes111.jar will no longer be provided. Furthermore, Oracle JDBC will only be delivered as JAR files, ZIP files will no longer be provided.


This release also provide a system property to set CHAR/NCHAR behavior.

IMPLICIT CONNECTION CACHE Prior to Oracle Database 10g, JDBC drivers offer support for connection caching, however there are limitations in terms of scalability, usability and manageability. As an example, all sessions are in the same database and authenticated as same user, there is no mechanism to cleanup stale connections; also, since all sessions belong to the same database and are authenticated as the same user, there is no way to cache a connection that is authenticated as another user. Pre-10g JDBC drivers cache management does not allow connection cache resize or refresh in the event that the cache may have gone stale; does not support searching for connections or reclaiming abandoned connections. These short comings fueled requirements for a new and improved connection caching mechanism, the Implicit Connection Cache. Implicit Connection Cache provides a rich set of features including: transparent or implicit access to the connection cache, support for caching any authenticated connection, the ability to refresh or recycle stale connections from the cache, connection retrieval based on user defined attributes, connection retrieval based on attributes and weights.

Figure 2 - JDBC Connection Caching

Transparent access to the Connection Cache By default, datasources allow physical connections to be obtained directly to the database. With the “Implicit Connection Caching”, by simply flipping the datasource property ConnectionCachingEnabled to true, connections are obtained from a connection cache instead, all while using the same standard getConnection() API. This greatly simplifies datasource and connection cache


access. Everything else is optional, and may be done on a need basis. For example, a set of connection cache properties that define the behavior of the cache may be specified optionally otherwise, default properties are used. // Example to show binding of OracleDatasource to JNDI // with relevant cache properties set on the Datasource. … // Set Datasource properties ods.setUser(“Scott”); … ods.setConnectionCachingEnabled(True); ods.setConnectionCacheName(“MyCache”); ods.setConnectionCacheProperties(cp); ctx.bind(“MyDS”, ods); … ods =(OracleDatasource) ctx. lookup(“MyDS”); // lookup cache Datasource //Transparent creation and retrieval of connection(s) from “MyCache” conn = ods.getConnection(); … conn.close(); // return connection to the cache … ods.close(); // close cache-enabled datasource

Support for Any User-Authenticated Connection A connection cache holds connections to a database. While a database does not impose any restriction on the connection authentication, a traditional cache might impose such limitation. The Implicit connection cache can handle any user-authenticated connection. For example, joe.blow connection can very well co-exist with a sue.miller connection, in the same connection cache.

Connection Retrieval based on User defined Attributes The Implicit Connection Cache supports the idea of striping (adding states to) a connection before returning it back to the cache, allowing user-defined set of attributes to be applied on a checked out connection. These attributes can later be used to retrieve the same connection from the cache.

Example 1: Retrieval based on Connection Attribute NLS_LANG

// Look up the datasource object javax.sql.Datasource ds = (javax.sql.Datasource) ctx.lookup(MyOracleDatasource); // get a connection from MyCache java.util.Properties connAttr = null; connAttr.setProperty(“NLS_LANG”, “ISO-LATIN-1”); conn = ds.getConnection(connAttr); // retrieve connection - NLS_LANG … conn.applyConnectionAttributes(connAttr); // apply attributes


Statement stmt = conn.createStatement(); stmt.execute(“select empname from emp”); … conn.close(); // release the connection back to MyCache

Example 2: Retrieval based on Connection Attribute Isolation level

… java.util.Properties connAttr = null; connAttr.setProperty(“TRANSACTION_ISOLATION”, “SERIALIZABLE”); conn = ds.getConnection(connAttr); // retrieve connection that matches Transaction Isolation … conn.close(connAttr); // another way to apply attributes to the connection

Example 3: Retrieval based on Connection Attribute, Connection tags (Reserved connection)

… java.util.Properties connAttr = null; connAttr.setProperty(“CONNECTION_TAG”, “JOE’S_CONNECTION”); conn = ds.getConnection(connAttr); // retrieve connection that matches Joe’s connection … conn.close(connAttr); // apply attributes to the connection … conn = ds.getConnection(connAttr); // this will retrieve Joe’s connection

Applying Connection Attributes to a Cached Connection There are two ways to apply a connection attribute to a connection in the cache.

By calling applyConnectionAttributes(java.util.properties connAttr) API on the connection object. This simply sets the supplied attributes on the connection object. Its possible to apply attributes incrementally using this API, allowing users to apply connection attributes over multiple calls. For example, NLS_LANG may be applied by calling this API from module A. The next call from module B, may then apply the TXN_ISOLATION attribute, and so on.

By calling close(java.util.properties connAttr) API on the connection object. This API closes the logical connection and then applies the supplied connection attributes on the underlying PooledConnection (physical connection). The attributes set via this close() API overrides the attributes, if any, set using the applyConnectionAttributes() API.

The following example shows a call to close(connectionAttributes) API on the connection object, that lets the cache apply the matched connectionAttributes back on the PooledConnection, before returning it to the cache. This ensures that when a subsequent connection request with the same connection attributes is made, the cache would find a match. // Sample connection request and close


java.util.properties connAttr = null; connAttr.setProperty(“NLSLANG”, “ISO-LATIN-1”); conn = ds.getConnection(connAttr); // request connection based on attributes java.util.properties unmatchedAttr = conn.getUnMatchedConnectionAttributes(); … --- App Server code applies unmatched attributes to the connection, either by calling PL/SQL procedures or SQL, before using the connection. --- --- work --- … conn.close(connAttr); // apply attributes to connection

Connection Cache Properties It is easy to set limits and tune the connection cache using a set of connection cache properties. Cache properties are set either while creating the cache for the first time, on the datasource as connection cache properties, or when re-initializing the cache, via the Connection Cache Manager. Refer to the section on Connection Cache Manager APIs for details on how to set cache properties on a cache.

MinLimit: this sets the minimum number of PooledConnections the cache maintains. This guarantees that the cache will not shrink below this minimum limit. This property does not initialize the cache with minimum number of connections1. Refer to InitialLimit property for priming of cache information. The default value is 0.

MaxLimit: this sets the maximum number of PooledConnections the cache can hold. The default value is unbound, meaning that there is no MaxLimit assumed. Since the connection cache does not assume the maximum limit, the connection cache is only limited by the number of database sessions configured for the database. In other words, connections in the cache could reach as much as the database allows.

InitialLimit: this sets the size of the connection cache when the cache is initially created or reinitialized. When this property is set to a value greater than 0, that many connections are pre-created and are ready for use. This property is typically used to reduce the “ramp up” time in priming the cache to its optimal size. The default is set to 0.

Abandoned Connection Timeout Support Implicit Connection Cache can handle Abandoned Connections, in addition to inactive or idle connections. Abandoned or orphaned connections are those that have been checked out of the connection cache, but never returned to the cache. There could be many reasons for connections to be abandoned. For example, a user thread may get killed after it checks out a connection from the cache. When

1 As was the case with OracleConnectionCacheImpl


a connection is abandoned, it is very desirable to automatically detect and reclaim these connections back to the cache, and that is precisely what the AbandonedConnectionTimeout property on the connection cache does. Setting this property to a valid timeout value starts a heartbeat monitoring process on this connection that is checked out. A heartbeat is any SQL activity to the database, on this checked out connection. When a heartbeat is not registered on the connection for the specified period of time, the connection is considered abandoned and is automatically claimed and put back to the cache.

Statement Caching Support The MaxStatementsLimit connection cache property sets the maximum statements to keep open for a connection cache. If cache is reinitialized with this property and if more cursors are cached than specified, the extra cursors are closed. The default value is 0.

Connection Cache Manager The Connection Cache Manager provides a centralized way to manage one or more connection caches.

Figure 3 Connection Cache Manager

There is a single instance of Connection Cache Manager per VM, managing all of the connection caches. This instance of the Connection Cache Manager must be obtained before using any of the Connection Cache Manager functionality. A static getter method, provided on the Connection Cache Manager class must be


called to obtain the Connection Cache Manager instance. The Connection Cache Manager plays two major roles:

Cache Management and Maintenance: The Connection Cache Manager is responsible to create the cache, maintain the sanity of the cache and remove a cache from existence. The Connection Cache Manager “knows” about the existence of each cache. Each cache is managed independently. A rich set of APIs is provided to perform the Connection Cache Manager tasks.

Binding a connection cache to the datasource: the Connection Cache Manager ensures the association of a connection cache with its datasource object. This is enforced every time a connection cache is created, removed or reinitialized. This ensures an efficient way to access the connection cache and retrieve connections from the cache, for every getConnection() request on the datasource.

It is possible to explicitly create a cache using the Connection Cache Manager API, as opposed to letting the cache to be created transparently when accessing the datasource. If a cache already exists, then the first invocation to obtain a connection on the corresponding data source skips the cache creation process and simply routes the connection request to the cache. Once the cache is chosen, the connection retrieval process is delegated to the cache itself. The cache searches for the connection either based on user authentication or performs a more elaborate search based on Connection Attributes.

Connection Recycling Support Over a period of time, the connection cache accumulates stale connections. There are two modes for recycling or refreshing stale connections in the cache: Refresh_Invalid_Connections, and Refresh_All_Connections.

When invoked with Refresh_Invalid_Connections, each PooledConnection in the cache is checked to see if they are valid. If an invalid PooledConnection is found, the connection’s resources are removed and replaced with a new PooledConnection. The test for validity is basically a simple query to the dual table: select 1 from dual.

When invoked with Refresh_All_Connecions, all available connections in the cache are closed and replaced with new valid physical connections.

Dynamic Reconfiguration Support Implicit Connection Cache allows dynamic reconfiguration of the cache properties by reinitializing the cache using the specified new set of cache properties. The new properties take effect on all PooledConnections newly created as well as PooledConnections that are not in use. For connections that are in use, the new properties take effect only after they are returned to the cache.


Monitoring the Connection Cache The following APIs may be invoked on the Connection Cache Manager to obtain cache information, such as the number of connections checked out, or the number of connections available in the cache.

getNumberOfAvailableConnections

int getNumberOfAvailableConnections(String cacheName)

This API returns the number of connections in the connection cache, that are available for use. The value returned is a snapshot of the number connections available in the connection cache at the time the API was processed and hence a statistical value.

getNumberOfActiveConnections

int getNumberOfActiveConnections(String cacheName)

This API returns the number of checked out connections. These are connections that are active or busy, and hence not available for use. The value returned is a snapshot of the number of checked out connections in the connection cache at the time the API was processed and hence a statistical value.

getCacheProperties

java.util.properties getCacheProperties(String cacheName)

This retrieves the cache properties for the specified cache name.

getCacheNameList

String[] getCacheNameList()

This API returns all the connection cache names that are known to the Connection Cache Manager. The cache name(s) may then be used to manage connection caches using the Connection Cache Manager APIs.

Connection Retrieval Based on Attributes and Weights Connections may be searched from the connection cache based on a combination of ConnectionAttributes as well as attribute weights. Weights are assigned to each key in a ConnectionAttribute, as a one-time operation and a set on the cache as cache properties. The cache property AttributeWeights are java.util.Properties that allows setting of attribute weights. Each weight is an integer value that defines the expensiveness of the key. Once the weights are specified on the cache, connection requests are made on the datasource calling getConnection(connectionAttributes). These connectionAttributes are Keys and their associated values. The connection retrieval from the cache involves searching for a connection that satisfies a combination of:

• key/value match on a connection from the cache


• maximum total weight of all the keys of the connectionAttributes that were matched on the connection

Note: The connection cache property ClosestConnectionMatch must be set to true, for connection retrieval based on weights to work.

Consider the following example. A cache is configured with AttributeWeights as follows:

java.util.properties cacheProps = new Properties(); java.util.properties cacheWeights = null; cacheWeights.setProperty(“NLSLANG”, “10”); cacheWeights.setProperty(“SecurityGroup”, “8”); cacheWeights.setProperty(“Application”, “4”); … // set weights on the cache cacheProps.put(“AttributeWeights”, cacheWeights); // Enable ClosestConnectionMatch cacheProps.put(“ClosestConnectionMatch”, “true”);

… Once the weights are set, a connection request could be made as: java.util.properties connAttr = null; connAttr.setProperty(“NLSLANG”, “ISO-LATIN-1”); connAttr.setProperty(“SecurityGroup”, “1”); connAttr.setProperty(“Application”, “HR”) // Request connection ds.setCacheName(“MyCache”); // First retrieval of connection from myCache conn = ds.getConnection(connAttr); … conn.close(connAttr); // apply attributes on the connection … // Next retrieval finds the “striped” connection in the cache conn = ds.getConnection(connAttr); …

This getConnection() request tries to retrieve a connection from the cache, MyCache. The connection matching and retrieval from the cache involves the following:

A closest match based on the attribute key/value and their associated weights are used when the ClosestConnectionMatch property is set. For example, a closest match may be a connection that contains attribute match of NLS_LANG and APPLICATION, but not SECURITY_GROUP. It is also possible to find connections that match some keys of the original list, but their combined weights are the same. For example, connection1 could have a match of NLS_LANG with its associated weight of 10, where as connection2 may have an attribute match of SECURITY_GROUP and APPLICATION with their combined weight of 12. In this case, it is desired that connection2 is returned. In


other words, connection2 is the closest match and more expensive to reconstruct (from the caller’s perspective) as opposed to connection1. When none of the connectionAttributes match a new connection is returned. The new connection is created using the user and password set on the datasource. Once the connection is returned, the user can invoke getUnMatchedConnectionAttributes() API on the connection object to return a set of attributes (java.util.Properties) that did not match the criteria. These unmatched attribute list is used by the caller (or application) to re-initialize these values before using the connection.

Multi-cache Support Connection Cache Manager supports co-existence of more than one cache. Each cache identified by a unique name, is tightly bound to a datasource. Each cache is either created transparently when getConnection() requests are made on a cache enabled datasource or is created explicitly in the middle tier via the Connection Cache Manager API. Using multiple cache enabled data sources provides the following benefits:

• Request connections to more than one datasource (or database service), especially when each of these datasources point to a separate underlying database service.

• Manage all caches configured, via the Connection Cache Manager. This makes managing caches easy, without the burden of unnecessary book keeping in Application Server code (code using Connection Cache Manager).

There are no limits imposed by the Connection Cache Manager on the number of caches that can be created. The limitation may come from resources available on the JVM or in the Oracle database server.

Once a cache is created, it may either be explicitly removed via the Connection Cache Manager, or is removed when the datasource is closed after use, via the datasource close() API.

FAST CONNECTION FAIL-OVER Fast Connection Fail-over works in conjunction with the Implicit Connection Caching mechanism and a RAC database. The Fast Connection Fail-over mechanism works, by handling Service DOWN or Service UP events and Host DOWN events. The DOWN event processing always cleans up the bad connections from the cache. The DOWN event processing enables an automatic detect-and-fix mechanism to handle any instance or host failures in a RAC environment. The UP event processing does Load Balancing of available connections in the cache.


Enabling Fast Connection Fail-over The mechanism is enabled on a cache-enabled datasource, by simply setting the datasource property FastConnectionFailoverEnabled to true. Note that in order to turn on Fast Connection Fail-over, Implicit Connection Caching must already be enabled. Once enabled, the RAC event processing is completely transparent and the user of the connection cache will be able to retrieve good connections, immaterial of the failures that may occur on the RAC nodes/instances. // Example to show binding of OracleDataSource to JNDI // with relevant cache properties set on the datasource. import oracle.jdbc.pool.*; // import the pool package Context ctx = new IntialContext(ht); OracleDataSource ods = new OracleDataSource(); // Set Datasource properties ods.setUser(“Scott”); ods.setPassword(“tiger”); ods.setConnectionCachingEnabled(True); ods.setConnectionCacheName(“MyCache”); ods.setConnectionCacheProperties(cp); setURL("jdbc:oracle:thin:@(DESCRIPTION= (LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=TCP)(HOST=host1) (PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=service_name)))"); ods.setFastConnectionFailoverEnabled(true); // Enable fast connection failover ctx.bind(“MyDS”, ods); … ds = lookup(“MyDS”); // lookup datasource from the cache // implicitly create connection cache, that is set up for fast connection failover conn = ds.getConnection(); … conn.close(); // return connection to the cache … ods.close() // close datasource and cleanup the cache

RAC DOWN/UP Event Processing The Fast Connection Fail-over provides the following functionality:

Fast shutdown of connections in the connection cache, when RAC instance/node failures are detected: this prevents bad or invalid connections being handed out to application connection requests. For an application that depends on the Implicit connection cache for total connection management, the Fast Connection Fail-over mechanism provides maximum connection availability, transparently.

When a connection cache is setup against a multi-instance RAC database, database connections may end up on any of the RAC instances, as distributed by the database listener. When an instance goes down, due to an instance or host


failure, it brings down all the connections with it. For example, in a two node, two instance RAC cluster, consider a scenario where each of the instances were to have 50 connections each, for a connection cache primed up to 100 connections in the cache. If one of RAC instances goes down, there would instantly be 50 bad connections in the cache. This could potentially result in multiple bad connections being returned from the cache, which in turn could result in application or browser page errors.

Load Balancing of connections, when a RAC UP event is generated: in this model connections are established and load balanced to all active RAC instances, without waiting for application connection retries/requests. Note that for RAC setups, the service is almost always instantly available, except when the entire service is down.

Figure 4 Fast Connection Fail-Over Processing

Runtime Work-Request Distribution When Fast Connection Fail-over is enabled, every connection request (or work-request) is distributed across all active RAC instances. For example, if you have a four node RAC cluster, and connections are distributed across all four instances then every connection request is distributed across all the four active RAC instances. This distribution mechanism avoids sending work requests sequentially from the list of connections in the cache (in other words, avoids sending work-request to the same RAC instance).


Handling of In-Flight Transactions Fast Connection Fail-over works in conjunction with the Implicit connection cache, and the RAC database, by significantly improving the availability of valid and useful connections in the connection cache. If an application is in the middle of transaction, as an instance fails, it will be thrown an appropriate SQL exception, and the transaction will be rolled back. It is the Application’s or the Container’s responsibility to retry the connection request, and re-establish session state.

Fast Connection Fail-over and TAF The primary difference between Transparent Application Fail-over (TAF) and Fast Connection Fail-over mechanisms lies in how the connection retries occur. With the Fast Connection Fail-over, the retries are under the control of an application and may decide whether to re-throw the SQL Exception to the caller or whether to retry. Here is a list of the differences.

Connection Retries: FCF allows retry at the Application level, whereas TAF retries occur at the OCI/Net layer. Application layer (Example: EJB Container) fully controls retries

Integrated with the Connection Cache: Unlike TAF, FCF works in conjunction with the Implicit Connection Cache, and has complete control over connections managed by the cache

RAC Events Based: FCF is a RAC event based mechanism. This is much more efficient than detecting failures of network calls

Load Balancing Support: FCF supports UP event Load Balancing of connections across active RAC instances

NOTE: Currently, Fast Connection Failover should not be used in conjunction with TAF. The reason is that TAF works at a lower level than JDBC. Hence, when these features are used together, Fast Connection Fail-over mechanism may remove some of the TAF Fail-over’d connections.

CONCLUSION The constant evaluation of Oracle JDBC drivers results in the delivery of major enhancements in Oracle Database 10g JDBC including: re-architecture groundwork, unified drivers code base, best performing JDBC drivers for faster JDBC applications execution, comprehensive JDBC 3.0 support, best database connectivity for Web Services and GRID Services, best integrated drivers with the Oracle database, and compatible type-2 and type-4 drivers. In addition, this release delivers a new Implicit Connection Cache with a Cache Manager API for ISVs or J2EE Containers, and Fast Connection Fail-over mechanism for early data source connection failure and repair.


Best of Breed JDBC Drivers for J2Ee, WebServices, and GRID December 2003 Authors: Kuassi Mensah, Rajkumar Irudayaraj Contributing Authors: Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 www.oracle.com Oracle Corporation provides the software that powers the internet. Oracle is a registered trademark of Oracle Corporation. Various product and service names referenced herein may be trademarks of Oracle Corporation. All other product and service names mentioned may be trademarks of their respective owners. Copyright © 2002 Oracle Corporation All rights reserved.

Best of Breed JDBC Drivers for J2EE Web Services and GRID

Documents

Transcript of Best of Breed JDBC Drivers for J2EE Web Services and GRID