Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Maximize J2EE and database interoperability for performance

The right APM tool can improve the interoperability between your application's J2EE and database tiers

By Robert Maness, JavaWorld.com, 02/28/05

Things are not going well at Continental Flange. The corporate Website's performance has degraded to the point where frustrated customers are searching for other suppliers. The IT operations staff investigates and determines that a problem with the J2EE application is a major contributor to the poor response time. This puts immediate pressure on the J2EE development team to identify and resolve the problem.

After some initial investigation, the J2EE development team determines that the problem isn't in the J2EE tier, but can be traced to the database. The database team responds with arguments that the problem really is, after all, in the J2EE tier. Blamesmanship escalates, team spirit evaporates, confusion prevails, and customers and revenue continue to disappear.

This common scenario highlights a significant need: to support better interoperability between the J2EE and database tiers, IT departments need to be able to act more quickly and decisively.

The basic challenge: Naming the culprit

J2EE developers are often forced to participate in the blame game when lagging response times drive Website users away. The applications programmers develop on the middle tier must interoperate with the database, and when a performance bottleneck appears, it may show up as a problem on the J2EE tier when the database is the underlying cause. The real problem is interoperability. How do you optimally tune integration between those two tiers to maximize your application's performance? More to the point, how can you view the bottlenecks, identify the real troublemakers, and deal with them as quickly as possible?

Many APM (application performance management) tools are available to help identify and resolve performance bottlenecks. Two common approaches to finding bottlenecks in J2EE applications are:

1. You use a dashboard with colored alerts to monitor the status of your systems. Green means all is well; yellow or red means you have a performance problem to deal with. The dashboard can also report on response times from the different components of your application.
2. Instead of waiting for performance to deteriorate enough to trigger a dashboard alert, you take a proactive approach and try to identify excessive response times or excessive resource usage. You can do that by examining the top service requests (in terms of response time) and drill down to see what components they invoke.

Let's say you're a bank. One of your checking account customers has gone to your Website to get an account summary covering the last seven days. That customer clicks the Get Account Summary link.

Get Account Summary starts by invoking a specific URL through the Web browser. Underneath, of course, it invokes many components that interact to provide the right output. In your search for bottlenecks, you start from the top invocations (in many cases, that would be a servlet's doGet() or doPost() method) and traverse the invocation tree to look at all the components invoked to service Get Account Summary, and then the components that they invoked, and so on, down to the lowest level, which, in many cases, would be the SQL call to the database using JDBC (Java Database Connectivity).

 

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

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