Welcome!

Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

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.

Applicability:
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.

Structure
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 www.sys-con.com/weblogic/sourcec.cfm) 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.

Implementation
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)

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.


IoT & Smart Cities Stories
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...