Improved Performance with the EJBSelect Data Aggregation Patterns

Improved Performance with the EJBSelect Data Aggregation Patterns

When EJB 2.0 arrived I thought, "Wow, EJB has finally arrived!" With Container Managed Relationships (CMR) and a standard query paradigm I thought the nirvana of portable data layer-independent applications was just a few keystrokes away.

Well, time passed, and while CMR made navigating a foreign key relationship just a "get" away, I still found myself laboriously looping through Collections beans. Calling findByPK on every bean; tossing out the ones the application didn't want; and running up the in cache count for a lot of linking beans that I did not need anyway. How is this better than SQL? I want my JDBC!

Then one night, later than I would have liked, in an effort to recover from a TimedOutException without resurrecting my timeworn JDBC framework again, I stumbled upon something that brightened my world and restored my faith in humanity: the EJBSelect.

Intent: Maintain CMP Transaction Support While Boosting Performance
The thing I 've always loved about EJB Container Managed Persistence (CMP) has been that it handles all that nasty transaction stuff. None of that "Oh, I forgot to roll that part back" stuff. Of course, the painful part is that sometimes we're forced into some unwieldy code, with lots of nested loops, to get at the data we need. This leads to bulky code, which inevitably leads to bulky performance.

The bulky performance comes from the fact that in all that looping, you're loading lots of stuff just so you can navigate to other stuff. You don't need or care about it; you just need to navigate the schema so you can get what you really want. I don't know about you but Tom's first rule of performance tuning is "Don't make the machine do something it doesn't have to." Doing joins in application code blows that tenet to a place where the donuts are stale and the coffee is cold.

Tempted to Resort to JDBC

This "Let's just use JDBC" thing bothers me. I'm not bashing JDBC. I love JDBC. It can be the right tool for the right situation and EJB can be like using a sledgehammer on a thumbtack. The problem is, however, that as soon as you start to wander down that BMP road you're left with two options.

First, build your own persistence framework. Been there. Done that. The customer I did it for owns the rights and my current customer doesn't want to hear about the person months that will add to the schedule (read cost).

The second option is to wing it and hope that everyone on the team knows what they're doing. Well, I hate to admit it but I've been there and done that too and I'm not going back.

In Figure 1, for brevity's sake I distilled the various EJB interfaces into one class for each entity EJB. There are two important points to take away from this picture. First, notice the CMR relationships. Things are chained together nicely in a properly normalized way. Navigation is possible via what used to be called foreign keys. There is nothing terribly new here.

Second, notice the "ejbSelectCorporationsOpenInvoices". This lives in the CorporationBean class. It is not, and may not be according to the EJB 2.0 spec, visible from the local or remote interface of the bean. To access it you need to implement a business method in the bean class and expose that to the public interface. That is where "getCorporationsOpenInvoices" comes in. It is simply a pass-through method that calls "ejbSelectCorporationsOpenInvoices", passing the result of the instances "getCorporation" method as an argument.

Consequences: Who Knows What and Is It Fast Enough?
In the listings shown here (the source code for this article is online at the eventual solution has the application asking a Corporation entity for its "open" Invoices. We could argue over beers about whether a Corporation object is the right place to put the "is the invoice OPEN?" question, but the point here is I needed it to perform. The Invoice is a more philosophically pure place to encapsulate that question. That being said, this way rocked.

But was it fast enough? Okay, this is where I pull out my standard Golden Hammer Response. This is not a silver bullet. There are cases where resorting to JDBC may be your best option. In this case, however, this way rocked.

Okay, enough of me waxing eloquent, it's time to roll up our sleeves and dig into some code. First a little background. The customer for whom I was staying up late is in the food distribution business. They supply all the burgers, fries, and other good stuff to some of the largest restaurant chains in the country. The food distributor must deliver food to the individual restaurants but receives payment from the restaurant chains' corporate entity. So Invoices are issued at the Customer level and payments are received at the Corporation level. (Note that in the real world there is a hierarchy of Corporations, Franchise Groups, Divisions, and Customers. Payment and invoicing levels vary from chain to chain so we can't just slap corporation on the Invoice table.) When a payment comes in we need all the OPEN Invoices for the Corporation.

Another thing you want to know, since I'm going on about performance, is what kind of box the tests were run on. It's a Dell Inspiron 8200 with a 1.7GHz Pentium 4 and 512MB, of RAM. It's running Windows XP Pro, WebLogic 7.0 SP2, and hitting a local SQLServer 7.0 database. For the test I have one Corporation with 500 customers, each with five invoices (four CLOSED, one OPEN) for a total of 2500 invoices.

The first approach is a bit EJB 1.1-ish (see Listing 1). In our session bean code we start out by getting a reference to the Corporation. We then use Corporation's CMR relationship with Customer to get a Collection customer linked to the corporation. That's EJB 2.0 but then we loop through the customers. For each customer we get all of their invoices. Then we check each invoice to see if it's opened, keep the ones that are, toss out the ones that aren't.

EJB1.1 Joins are in the application code. Why can't we just use JDBC? The performance was poor too. On my test machine it took an average of 4,126 milliseconds to complete the operation and no wonder. Look at Figure 2. We loaded 500 customers just to get their invoices. Then we sorted through a pile of 2,500 invoices to find the 500 we wanted. Ugh!

Now let's look at a different approach. Remember the old days when you could just write a SQL to do something like this? Well, everything old is new again. EJBSelect is here and you can do that join in a deployment descriptor. Let's look at more code.

In Listing 2 you'll find the engine behind the EJB Select. EJBQL allows us to do joins by navigating the Abstract Schema the way we used to navigate the database schema. What it is doing is selecting the invoices with a state of "O"PEN that are "IN" the result set that is returned by joining Corporation, Customer, and Invoices on their foreign keys. Kind of like doing a JDBC call from your code.

Now look at Listing 3 and see what it does to our session bean code. We now have one loop and no if statements. We go from nine lines of code down to five. I've been writing applications since two character dates were a good idea and it's always been true: the more lines of code you can delete, the better.

"Neat trick, but what about performance?" Glad you asked. As a result we get just what we need. Look at Figure 3. The query loaded 1 Corporation bean and exactly 500 Invoice beans. The operation took an average of 337 milliseconds. That's 1,225% faster! I say that rocks.

Conclusion: Look Before You Jump
Anytime anyone makes a performance claim, even someone as honest and hard working as your humble author, everyone says "Oh, yeah. How did you cook those numbers?" Well I didn't and it's running in production and the nasty TimedOutException went away and I can go to sleep at a reasonable hour... Sorry, but even a salesperson couldn't cook the numbers by 1,225%. Well, okay maybe, but it would be tough.

Once again, I'm not saying it's a silver bullet or a golden hammer but it sure is a pretty nifty pair of pliers. Next time you're tempted to do the JDBC thing give it a shot. It may be a way to get that performance without losing CMP transaction handling.

More Stories By Tom Purcell

Tom Purcell's eighteen year IT journey has tracked the course of the industry from the glass house of the 80's, to the client-server of the 90's and on to the J2EE Enterprise applications of the new millennium. He has designed and developed applications on numerous platforms and has worked with Java extensively since he installed the first IBM mainframe JVM in 1997. Recently, he has helped engineer several successful J2EE applications in the accounting and travel industries. Tom is currently an architect with Chariot Solutions, a Java consulting company.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
Krishna K. Johulo 08/27/03 09:35:30 PM EDT