Prevent Stale DB Connections with the Latest OC4J : Page 2

Implicit Connection Caching to Keep Connections Fresh

Though connection caching (part of OC4J 9.0.3) and implicit connection caching (part of OC4J 10.1.3), which is also called connection pooling, are interchangeably used in technical discussions, they differ slightly. Both evolved from middle-tier connection management using data-sources. Connection caching, generally implemented in the middle tier, allows a single database connection to be shared among different applications.

When session beans request a database connection during ejbCreate(), the middle tier first looks in the pool for any available connections that would satisfy the request; if it finds them, the middle tier simply returns one of those connections. If the code releases the connection only during ejbRemove(), the connection is held up and eventually may become stale.

Implicit connection caching or connection pooling is a new JDBC 3.0-compliant connection cache implementation for data sources. The implicit connection cache is based on the concepts of physical and logical connections. The physical connections are the actual connections returned by the database, whereas the logical connections can be thought of as handles that the cache uses to manipulate the physical connections. Implicit connection cache uses the standard OracleDataSource APIs to get connections and services all connection requests from the connection cache after the underlying application enables caching.

Implementing implicit connection caching does not require any major changes to your existing application other than modifying the data-sources configuration, but it makes a big difference functionally. Session beans can still make the connection during ejbCreate(), but they are returned only as logical connections. Behind the scenes, OracleConnectionCacheManager ensures that the physical database connections are recycled and do not become stale.

Implicit Connection Caching in Action

While it is impractical to simulate a large-scale J2EE application's behavior with sample code, the accompanying code demonstrates the use of implicit connection caching.

It uses OC4J10.1.3 and the latest managed data sources configuration parameters as follows:

<managed-data-source
 jndi-name="jdbc/ManagedDS"
 description="Managed DataSource"
 connection-pool-name="myConnectionPool"
 name="ManagedDS"/>

<connection-pool
 name="myConnectionPool"
 min-connections="10"
 max-connections="30"
 inactivity-timeout="30">
  <connection-factory 
   factory-class="oracle.jdbc.pool.OracleDataSource"
   user="XXXX"
   password="XXXXX"
   url="jdbc:oracle:thin:@IPXXX:1521:databasenameXXXX"/>
   <property name="loginTimeout" value="30"/>
  </connection-factory>
</connection-pool>

The client application connects to the EJB and invokes the doDBService() method. The same client code can be made into a multi-threaded application to simulate the load. But be aware—it may stall your colleagues' work.

Previous Page

Next Page