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
The Master of Science in Artificial Intelligence (MSAI) provides a comprehensive framework of theory and practice in the emerging field of AI. The program delivers the foundational knowledge needed to explore both key contextual areas and complex technical applications of AI systems. Curriculum incorporates elements of data science, robotics, and machine learning-enabling you to pursue a holistic and interdisciplinary course of study while preparing for a position in AI research, operations, ...
CloudEXPO has been the M&A capital for Cloud companies for more than a decade with memorable acquisition news stories which came out of CloudEXPO expo floor. DevOpsSUMMIT New York faculty member Greg Bledsoe shared his views on IBM's Red Hat acquisition live from NASDAQ floor. Acquisition news was announced during CloudEXPO New York which took place November 12-13, 2019 in New York City.
Codete accelerates their clients growth through technological expertise and experience. Codite team works with organizations to meet the challenges that digitalization presents. Their clients include digital start-ups as well as established enterprises in the IT industry. To stay competitive in a highly innovative IT industry, strong R&D departments and bold spin-off initiatives is a must. Codete Data Science and Software Architects teams help corporate clients to stay up to date with the mod...
The Japan External Trade Organization (JETRO) is a non-profit organization that provides business support services to companies expanding to Japan. With the support of JETRO's dedicated staff, clients can incorporate their business; receive visa, immigration, and HR support; find dedicated office space; identify local government subsidies; get tailored market studies; and more.
Tapping into blockchain revolution early enough translates into a substantial business competitiveness advantage. Codete comprehensively develops custom, blockchain-based business solutions, founded on the most advanced cryptographic innovations, and striking a balance point between complexity of the technologies used in quickly-changing stack building, business impact, and cost-effectiveness. Codete researches and provides business consultancy in the field of single most thrilling innovative te...
Atmosera delivers modern cloud services that maximize the advantages of cloud-based infrastructures. Offering private, hybrid, and public cloud solutions, Atmosera works closely with customers to engineer, deploy, and operate cloud architectures with advanced services that deliver strategic business outcomes. Atmosera's expertise simplifies the process of cloud transformation and our 20+ years of experience managing complex IT environments provides our customers with the confidence and trust tha...
With the introduction of IoT and Smart Living in every aspect of our lives, one question has become relevant: What are the security implications? To answer this, first we have to look and explore the security models of the technologies that IoT is founded upon. In his session at @ThingsExpo, Nevi Kaja, a Research Engineer at Ford Motor Company, discussed some of the security challenges of the IoT infrastructure and related how these aspects impact Smart Living. The material was delivered interac...
Intel is an American multinational corporation and technology company headquartered in Santa Clara, California, in the Silicon Valley. It is the world's second largest and second highest valued semiconductor chip maker based on revenue after being overtaken by Samsung, and is the inventor of the x86 series of microprocessors, the processors found in most personal computers (PCs). Intel supplies processors for computer system manufacturers such as Apple, Lenovo, HP, and Dell. Intel also manufactu...
Darktrace is the world's leading AI company for cyber security. Created by mathematicians from the University of Cambridge, Darktrace's Enterprise Immune System is the first non-consumer application of machine learning to work at scale, across all network types, from physical, virtualized, and cloud, through to IoT and industrial control systems. Installed as a self-configuring cyber defense platform, Darktrace continuously learns what is ‘normal' for all devices and users, updating its understa...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...