Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers| Heap dump analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Training online: Concurrency, Threading, GC, Advanced Java and more ... 

Question of the month: EJB performance vs. JDBC direct calls

Get rid of your performance problems and memory leaks!

Modern Garbage Collection Tuning
Shows tuning flow chart for GC tuning

Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:

Training online
Threading Essentials course

Get rid of your performance problems and memory leaks!

Back to newsletter 047 contents

What provides better performance, using EJBs or making direct JDBC calls?

This question gets asked pretty frequently in discussion groups as well as having being sent to us several times. It's one of the most frequently asked J2EE performance questions.

It would be safe to say that EJB performance can be, at most, no better than using direct calls and, at worst, considerably slower. The reasoning? In both cases, you're storing data in an object to a relational DB using SQL. Using EJB architecture places a framework between you and the data you want to store. Hence, there is inevitably an added cost to using an EJB compared to using plain JDBC.

But, industry considers EJB technology to be good enough to cover the cost. In many applications, the benefits of using EJBs does outweigh the performance cost of using them. Furthermore, the simple JDBC/EJB comparison assumes that your JDBC is as efficient as the EJB generated JDBC. That is by no means certain, as the container vendors can have specialist developers who are expert in producing optimal SQL. Also, the EJB container has the advantage of knowing when bulk efficiency optimizations can be applied to EJBs being operated on in groups or concurrently. And the container can also apply data-difference and dirty/non-dirty optimizations. All of which could be managed in pure JDBC code, but would make your persistency framework considerably more complex, and would put the onus on you rather than the persistence framework experts that should be used in building the container's persistency framework.

Having said all that, in practice, EJBs provide good enough persistency performance for applications that need EJBs (e.g. concurrent request transactional J2EE applications) as long as you do not follow any EJB performance antipatterns. In addition, you may need to supplement the project with some EJB performance enhancing patterns such as the FastLane Reader. But you would be doing the equivalent in JDBC too, were you to follow the plain JDBC path instead.

So, I guess the summary position is that plain JDBC is more efficient than using EJBs if you can use and generate optimal JDBC for your application. Otherwise, there is a tradeoff between the complexity of JDBC you need to maintain compared with what you get from your EJB container. And if you are using EJBs you need to be careful both to avoid antipatterns that would cause bad performance, and to use performance enhancing EJB patterns that eliminate some known EJB inefficiencies.

The team

Back to newsletter 047 contents

Last Updated: 2024-03-29
Copyright © 2000-2024 All Rights Reserved.
All trademarks and registered trademarks appearing on are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
RSS Feed:
Trouble with this page? Please contact us