Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

An ounce of prevention: Avoid J2EE data layer bottlenecks

Best practices for tackling data bottlenecks within J2EE environments

By Christopher Keene, JavaWorld.com, 04/05/04

Page 3 of 5

• Database replication: Replicating the database is one way to break up a flood of requests so they can be managed more efficiently. This also provides an effective way for boosting performance in a particular region. However, this can be an expensive approach, requiring additional servers and database licenses.
• Object caching within a J2EE server: Caching frequently used objects in-memory within the J2EE server reduces the database's load and improves response time. Some J2EE servers include limited caching for CMP (container-managed persistence) beans; however, this may not adequately address the performance issues, as described later in this article.
• Add-on object caching: Many stand-alone caching products are available for example products supporting the JCache API. However, these caches lack a tight integration with the J2EE persistent object lifecycle, leaving the cache's data integrity completely in the hands of each developer to manually manage.

Figure 3 illustrates the two common integrity errors in architectures that separate the data layer from the caching functionality. Each of these errors can cause the cache to serve inaccurate information to the application.

Figure 3. Two cache errors. Click on thumbnail to view full-sized image.

The first error is to miss local data changes—typically this occurs because the cache is not integrated with the persistent object lifecycle. For example, a transaction commit that affects the number of seats available on a flight may not cause the affected seat information to update in the local cache. The second cache error is to miss changes to data made by other servers in the cluster. For example, when an application server cancels a flight, other caches in the cluster may not update, causing cache queries for seat availability to produce inaccurate results.

Best practices for data-intensive applications

The toughest data bottlenecks occur in applications that have both complex object models and high transaction loads. The 50/50 rule described above can help architects and developers predict data bottlenecks.

For data-intensive applications, neither efficient mapping nor object caching by themselves can provide acceptable results. These applications require a more integrated data services layer solution that combines an efficient object-relational mapping layer with an intelligent object cache that is linked to the J2EE persistent object lifecycle.

Market-leading J2EE servers, such as WebLogic and WebSphere, offer some caching features, but these capabilities are limited in terms of the kinds of objects that can be cached and the level of integrity provided across a cache cluster. The following table describes some limitations of the caching provided within typical J2EE serves.

Cache function J2EE caching Intelligent caching Benefit Object access Objects accessible only within transactions Objects accessible across transactions Easier to access cached objects Object query By reference and primary key only By reference, primary key, attribute, relationship, and indexed queries Cache queries speed performance Object model Only caches simple objects, no relationships Caches complete object model, including relationships No "impedance mismatch" with cache Clustering Only sends invalidation sync messages Sends changed state in sync messages Clustered caches have complete state Completeness No sync messages sent for inserts, relationship changes All cache changes are replicated across caches Clustered caches are consistent with database Coherency No guaranteed messaging, can lose sync messages Guaranteed sync messaging Clustered caches have guaranteed integrity Portability Proprietary-caching capabilities not portable across J2EE servers Supports WebLogic, WebSphere, Java, C++, .Net Caches can sync across multiple platforms

For data-intensive applications, the data access layer must be developed to support the performance, scalability, and availability requirements of the business processes or a bottleneck results. Standard J2EE servers fail to meet these requirements out of the box, so data-intensive applications require either significant hand-coding to get around the J2EE framework's limitations or purchase of a third-party data services product that integrates mapping and caching transparently within the J2EE framework.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.