Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Prevent Stale DB Connections with the Latest OC4J : Page 2

Applying the same database connection code for all session beans can lead to stale DB connections in large enterprise Java applications. Oracle Containers for J2EE (OC4J) has a new mechanism to nip this problem in the bud.


advertisement

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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap