What is Implicit Connection Caching in OC4J 10.1.3.1?

OC4J 10.1.3 Datasources: An overview

OC4J 10.1.3 has simplified the data source classification. Now there are only two types of datasources

• Managed data source
• Native data source

Managed data sources are the data sources managed by OC4J. Specifically, a managed data source is an OC4J-provided implementation of the java.sql.DataSource that acts as a wrapper to a JDBC driver or data source.J2EE components access managed datasources via JNDI with no knowledge that the data source implementation is a wrapper.OC4J provides critical system infrastructure such as global transaction management, connection caching, error handling, for managed data sources.

Native data sources also implement the java.sql.DataSource interface & are provided by JDBC Vendors such as Oracle. Native data sources are not wrapped by OC4J at all.

Key advantages of managed data sources over native data sources are summarized in the following table:

1. Managed Data sources connections retrieved from a data source can participate in global transactions
2. Data source makes use of OC4J's connection pool and statement caches

What is connection caching?

Connection caching, generally implemented in the middle tier allows a single database connection to be shared among different applications. The middle tier maintains a pool of pre-allocated physical database connections. When applications request a database connection, the middle tier first looks into the pool to see if there are any available connections that would satisfy the request;if so, the middle tier simply returns one of those connections.

If the connection cache does not have any free-pooled connection instances, new pooled connection instances are created. A "free-pooled" connection instance is the one that has no logical connection associated with it.

When applications close the connections, the middle tier would send the connections back to the pool thereby avoiding the resource-intensive task of opening a new database connection each time a connection request is made.

Connection Caching in OC4J 10.1.3 Datasources 

Implicit Connection Cache

Prior to Oracle 10g , Oracle's JDBC connection cache interface was named OracleConnectionCache & its implementation was named OracleConnectionCacheImpl. The cache only supported pooling of physical connections to a particular database for a specified username.In Oracle 10g JDBC, the OracleConnectionCache interface and OracleConnectionCacheImpl class are both deprecated.

Implicit Connection Cache is a new JDBC-3.0 compliant connection cache implementation for data sources.

The implicit connection cache works on the concepts of physical and logical connections. The physical connections are the actual connections returned by the database & the logical connections can be thought of handles used by the cache to manipulate the physical connections.

Implicit connection caching also provides a new class OracleConnectionCacheManager so that applications can use its rich set of administrative APIs to create,manage& maintain connection cache in an effective way.

How to configure Connection Cache Declaratively in OC4J 10.1.3.1?

In OC4J, navigate to ‘Administration tab’. Click on “JDBC Resources”. Now in the ‘Connection Pools’ division, click ‘Create’.

Besides the standard parameters such as maximum pool size, minimum pool size, maximum number of attempts, maximum period of time of inactivity, etc OC4J 10.1.3 offers various new parameters such as

• validate-connection
• abandoned-connection-timeout

Both the above parameters play a very important role in ensuring that DB connections never go stale. When set to true, validate-connection first validates the connection before giving it to the session bean.Similarly abandoned-connection-timeout is explicitly applicable for logical connections. The connection manager monitors the database-execute calls issued by each DB connection & based on the inactive time reclaims & recycles the connection.