Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

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

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.

Figure 2. The 50/50 rule of thumb. Click on thumbnail to view full-sized image.

Many basic applications have a low risk of data bottlenecks, and the performance provided by a standard J2EE server is adequate. Model-intensive applications are characterized by numerous data classes and/or complex relationships between objects. Transaction-intensive applications currently have or are anticipated to have a high rate of requests as demand grows. Data-intensive applications suffer from both a large number of data classes and a high peak transaction rate. The rest of this article addresses best practices for addressing the data bottlenecks created by these types of applications within a J2EE environment.

Best practices for model-intensive applications

For applications with a small number of data classes, it is relatively easy to hand-tune the mapping of application components to a relational database. For larger object models, however, hand-coding the data class implementations or specifying the mapping through descriptors becomes increasingly unmanageable.

In general, any application that has an object model with 20 or more data objects will experience performance issues related to the object-relational mapping (ORM) challenges. Inefficient mappings will cause the application to bottleneck on time-consuming database queries. Several approaches address ORM bottlenecks:

  • Use lazy loading: One common mistake with data objects is to fetch entire objects or object hierarchies from the database when an object slice or hierarchy node is sufficient for the application's needs. Loading data only when absolutely needed is one way to reduce the overall database traffic.
  • Understand J2EE mapping limitations: J2EE servers offer features for automating the mapping between entity beans and relational data. These automated mappings save considerable development time. Sometimes, however, simplistic object-relational mappings may perform poorly and make accessing existing data difficult.
  • Use stored procedures: One way to optimize database performance for complex data is to take advantage of the database's stored procedure facilities. The data classes then map directly to a set of stored procedures for reading and writing the data.
  • Use native database APIs: JDBC (Java Database Connectivity) APIs have known inefficiencies relative to native C database libraries, such as Oracle Call Interface (OCI). In addition, native APIs present tuning parameters and functionality that is unavailable through the generic JDBC layer offered by a J2EE server.


Best practices for transaction-intensive applications

For applications that must support many requests per second, data bottlenecks are almost guaranteed to occur. This is particularly true for applications with distributed Web-based deployment and subsecond response requirements.

1 | 2 | 3 | 4 |  Next >

Discuss

Start a new discussion or jump into one of the threads below:

Subject Replies Last post
. Too shallow to be useful
By Art Majors 		4 04/22/08 06:03 AM
by Anonymous
. An ounce of prevention: Avoid J2EE data layer bott
By JavaWorldAdministrator
( Pages 1 2 all ) 		28 04/22/08 06:02 AM
by Anonymous
. OODBMS for model intensive
By Harel 		0 04/22/08 06:02 AM
by Anonymous
. What a shallow article
By GKL 		0 04/09/04 12:55 PM
by Anonymous
. Data Layers
By L Cismaru 		0 04/05/04 08:49 PM
by Anonymous


Resources