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) 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
IoT & Smart Cities Stories
Business professionals no longer wonder if they'll migrate to the cloud; it's now a matter of when. The cloud environment has proved to be a major force in transitioning to an agile business model that enables quick decisions and fast implementation that solidify customer relationships. And when the cloud is combined with the power of cognitive computing, it drives innovation and transformation that achieves astounding competitive advantage.
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.
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
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...
Early Bird Registration Discount Expires on August 31, 2018 Conference Registration Link ▸ HERE. Pick from all 200 sessions in all 10 tracks, plus 22 Keynotes & General Sessions! Lunch is served two days. EXPIRES AUGUST 31, 2018. Ticket prices: ($1,295-Aug 31) ($1,495-Oct 31) ($1,995-Nov 12) ($2,500-Walk-in)
IoT is rapidly becoming mainstream as more and more investments are made into the platforms and technology. As this movement continues to expand and gain momentum it creates a massive wall of noise that can be difficult to sift through. Unfortunately, this inevitably makes IoT less approachable for people to get started with and can hamper efforts to integrate this key technology into your own portfolio. There are so many connected products already in place today with many hundreds more on the h...
Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
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...