Connecting the Java World to Grid-Enabled Databases

Sky-Tiger

In-Flight Transactions
If an application is midtransaction when an instance fails, it will be thrown an appropriate SQL exception and the transaction will be rolled back. It's the responsibility of the application or the container to retry the connection request and reestablish session state.

Simplifying JDBC Connection Caching
As summarized in Table 1, the new Oracle Database10g JDBC Implicit Connection Cache has been designed to overcome existing JDBC Connection Caching limitations as listed in Table 1, by providing:

Transparent access to the cache
Support for multiple identities
The ability to retrieve connections based on user-defined attributes and weights
The ability to refresh or recycle stale connections from the cache
To take advantage of these capabilities, simply customize your environment by explicitly setting properties on the connection cache properties or connection.

Sky-Tiger

Transparent Access to the Cache
By default, the getConnection() method in the standard OracleData-Source API creates a new database session and a physical database connection, thus incurring performance and scalability penalties. With Implicit Connection Caching, once the DataSource property ConnectionCachingEnabled has been set to true, the getConnection() method will service all connection requests from the connection cache.

ods.setConnectionCachingEnabled(True);
ods.setConnectionCacheName("MyCache"); // optional
ods.setConnectionCacheProperties(cp); // optional
ctx.bind("MyDS", ods);
ods =(OracleDataSource)
// lookup DataSource
ctx.lookup("MyDS");

A JDBC 10g Connection cache can be created either implicitly by the first invocation of the getConnection() method or explicitly by using the Connection Cache Manager API. The Connection Cache Manager is especially useful for developers working with J2EE containers and ERP frameworks since it shields the infrastructure from the complexity of managing connection cache.

// This call would create a "MyCache" cache and a
// connection from "MyDS"data source will be created and returned
conn = ods.getConnection();

// This call would create a "MyCache" cache and a
// connection to "MyDS", authenticated by "Scott" will be created
conn = ods.getConnection("SCOTT","TIGER");

Subsequent getConnection() invocations will either create a new connection (if the cache was not previously initialized) or retrieve an existing connection from the cache. Once the connection is retrieved, you can proceed with statement creation.



         // Create a Statement
  Statement stmt = conn.createStatement ();
  ...

  // Close the Statement
  stmt.close();
  stmt = null;

The cache can be populated in one of two ways: by preinitializing it using the Cache Manager APIs or, incrementally, upon the release of connection(s) back to the cache. When returning a connection to the cache, applications can save current connection attributes settings for future use (see attribute-based retrieval, below).

// return this connection to the cache
conn.close();
conn = null;

Sky-Tiger

Caching Multiple Identities
While a database does not impose any specific restrictions on the connection authentication, a traditional cache might impose a limitation on the connections it can manage, requiring that they all use the same username/password combination, for example.

The Implicit Connection Cache can handle any combination of user-authenticated connections. For example, a joe.johnson connection can coexist very well with a sue.miller connection in the same connection cache.

Connection Retrieval Based on User-Defined Attributes
One of the valuable new features in the Implicit Connection Cache is connection striping.

Connection striping, or labeling, consists of applying user-defined attributes to a connection and making their state persist when the connection is returned to the cache. This speeds up future connection retrieval since cached connections don't have to reinitialize a block of state every time. These attributes can later be used to retrieve the same connection from the cache, as follows.

Sky-Tiger

Example 1: Retrieving a connection based on the NLS_LANG attribute:

// get a connection from the cache with NLS_LANG attribute
java.util.Properties connAttr = null;
connAttr.setProperty("NLS_LANG", "ISO-LATIN-1");
conn = ds.getConnection(connAttr);

Example 2: Retrieving a connection based on the isolation-level attribute:

java.util.Properties connAttr = null;
connAttr.setProperty("TRANSACTION_ISOLATION", "SERIALIZABLE");

// retrieve a connection that matches Transaction Isolation
conn = ds.getConnection(connAttr);
...
// this call will preserve attr settings for this connection
conn.close(connAttr);

Example 3: Retrieving a connection based on the connection tag and connection attribute:

java.util.Properties connAttr = null;
connAttr.setProperty("CONNECTION_TAG", "JOE'S_CONNECTION");
// retrieve connection that matches Joe's connection
conn = ds.getConnection(connAttr);

// apply attributes to the connection
conn.close(connAttr);

// This will retrieve Joe's connection
conn = ds.getConnection(connAttr);

Sky-Tiger

Applying Connection Attributes to a Cached Connection
A connection attribute can be applied to a connection in the cache in two ways.

One approach is to call the applyCon-nectionAttributes(java.util.properties connAttr) API on the connection object. This simply sets the supplied attributes on the connection object. It's possible to apply attributes incrementally using this API, letting users 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 can then apply the TXN_ISOLATION attribute, and so on.

A second approach is to call the 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 override any attributes set using the applyConnectionAttri-butes() API.

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

// Sample connection request and close
java.util.properties connAttr = null;
connAttr.setProperty("NLSLANG", "ISO-LATIN-1");
// request connection based on attributes
conn = ds.getConnection(connAttr);

// apply attributes to connection
conn.close(connAttr);

Sky-Tiger

Connection Retrieval Based on Attributes and Weights
Connections may be selectively retrieved from the connection cache based on a combination of ConnectionAttributes and attribute weights.

Weights are assigned to each key in a ConnectionAttribute in a one-time operation that also changes cache properties. The cache property CacheAttributeWeights is one of the java.util.Properties that allows the setting of attribute weights. Each weight is an integer value that defines how expensive the key is in terms of resources.

Once the weights are specified on the cache, connection requests are made on the data source by calling getConnection(connectionAttributes). The connectionAttributes argument refers to keys and their associated values.

The connection retrieval from the cache involves searching for a connection that satisfies a combination of the following:

A key/value match on a connection from the cache
The maximum total weight of all the keys of the connection-Attributes that were matched on the connection
Consider the following example in which a cache is configured with CacheAttributeWeights (see Listing 2). (Listings 2-3 can be downloaded from www.sys-con.com/java/sourcec.cfm.)
Once the weights are set, a connection request could be made as in Listing 3.

The getConnection() request tries to retrieve a connection from the MyCache cache. In connection matching and cache retrieval, one of two things can happen:

An exact match is found. As in the above example, an exact match is a connection that satisfies the same attribute values and all the keys defined by Keys (NLS_LANG, SecurityGroup, and Application).
An exact match is not found. In this case, the closest match based on the attribute key/value and its associated weights is used (but only if the ClosestConnectionMatch property is set).
Once the connection is returned, the user can invoke the getUnMatchedConnectionAttributes() API on the connection object to return a set of attributes (java.util.Properties) that did not match the criteria. The unmatched attribute list can then be used by the caller (or application) to reinitialize these values before using the connection.
Conclusion
This article highlighted a new set of Java data access requirements that have emerged when executing in an enterprise grid environment while also outlining how Oracle Database 10g JDBC tackles the challenges that these requirements present.

Whether you're using JDBC directly in applications via a run-time container such as an EJB container or through an O/R mapping framework such as Toplink, the latest Oracle JDBC drivers offer reliable and highly available data sources in RAC and grid environments and significantly simplify a range of data source connectivity issues for Java developers.

Oracle has proposed these new features to the JSR 221 (JDBC 4.0 specification) expert group. It hopes to see JDBC Connection Pool management and high-availability support for data sources within enterprise grid environments become part of the JDBC 4.0 standard.