Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

An ounce of prevention: Avoid J2EE data layer bottlenecks

Best practices for tackling data bottlenecks within J2EE environments

  • Print
  • Feedback

J2EE application servers provide scalable performance for a wide range of applications. However, the general-purpose nature of J2EE, which aims to address the needs of every enterprise, also limits its ability to provide a best-of-breed solution for mission-critical applications. In particular, data-intensive applications expose a serious data bottleneck in all J2EE server architectures.

A recent survey of 360 J2EE users found that 57 percent of application performance and availability issues can be traced to inefficient data access problems, and only 42 percent of applications perform as planned during initial deployment. Not surprisingly, the survey went on to state that Java applications fail to meet user expectations 60 percent of the time. Worse yet, a 2004 survey conducted by Forrester Research found that more than two-thirds of respondents discovered application performance problems only when a user called the help desk.

Typically, J2EE servers convert every request for persistent data into one or more SQL statements. For applications with complex object models and heavy request volumes, this approach creates inevitable problems, as illustrated in Figure 1.

Figure 1. J2EE application server bottleneck. Click on thumbnail to view full-sized image.

This article defines the three most common causes of application data bottlenecks and offers a proactive approach for eliminating them. It also illustrates the architecture using a real-world J2EE application with a data services layer that has been deployed globally and is now providing high performance 24-7.

Indicators of potential application data bottlenecks

The two application characteristics that most frequently contribute to data bottlenecks are:

  1. The number of data objects, which drives the complexity of the object-relational mapping (mapping the entity bean to a persistent store)
  2. The peak transaction rate, which drives the volume of database requests


Applications in jeopardy of experiencing serious problems have one of the following three requirements:

  • Model-intensive requirements: As the size of the application object model grows, the difficulty of defining an efficient object-relational mapping increases. Highly efficient mapping is necessary to prevent mapping bottlenecks.
  • Transaction-intensive requirements: As the application request volume grows, the database will become a bottleneck based on the sheer volume of database queries. Intelligent caching is needed to prevent query bottlenecks.
  • Data-intensive requirements: For applications with both complex object models and high request volumes, eliminating data bottlenecks requires a more systemic approach. A data services layer is data access infrastructure software that integrates mapping and caching transparently within a J2EE server to eliminate data bottlenecks for data intensive applications.


The 50/50 rule of thumb

While enterprise applications are complex and may perform poorly for a variety of reasons, a good rule of thumb for predicting data bottlenecks is the 50/50 rule. J2EE applications that have more than 50 data classes and/or more than 50 transactions per second during peak times are much more likely to experience serious data bottlenecks. Figure 2 illustrates how to assess your application using the 50/50 rule for data bottlenecks.

  • Print
  • Feedback

Resources