JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection 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 JProfiler 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 JavaPerformanceTuning.com team

Back to newsletter 047 contents