File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes EJB and other Java EE Technologies and the fly likes EJB vs JDBC Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "EJB vs JDBC" Watch "EJB vs JDBC" New topic


Rahul JG
Ranch Hand

Joined: Jun 05, 2002
Posts: 44
Given an application which requires a lot of database calls, which of JDBC or EJB would be faster, and how to choose one technology over the other?

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17410

JDBC will usually be faster, but harder to maintain. EJBs are good for cases where having a prewritten (and pre-debugged!) system that caches and does transaction management is important.
I generally program flexible first, then measure and tune where needed. I learned a long time ago that the places where you "know" performance is an issue are almost never the places where it actually is. As has been said before - it's easier to speed up a clean design than to unsnarl an "efficient" one that doesn't work.

An IDE is no substitute for an Intelligent Developer.
Jes Sie
Ranch Hand

Joined: Jul 24, 2001
Posts: 188
I think it's quite hard to compare that way. Afterall, the underlying pipelines of Entity Beans are using JDBC calls, right?

Thank you.<br /> <br />- Jess Sie<br /> <a href="" rel="nofollow"></a>
Rishi Singh
Ranch Hand

Joined: Dec 09, 2000
Posts: 321
Hi Rahul,
It depends upon the architecture which one is implementing.If you want the services of transaction management, security, and connection pooling ,OR/mapping available then u go for entity beans wherein these features are provided by your application server, whereas if you want to only acess database tables where the data accessed is not tht frequent and u need not have to take care of synchronization issues u can use plain JDBC calls.
Mind you u can use JDBC with JTA to programm whatever the EJB container gives the decision boils down to how complex and big is your transactions.
Sheetal Engineer

Joined: May 21, 2002
Posts: 4
I would put it like this:
EJB container provides services like declarative transaction, security etc. This makes application development easy. EJB Container also maintains a pool of beans to service multiple clients. An instance is taken out of the pool when a client sends a request. There is no need to initialize the bean with any information. When the application user base is large, this helps tremendously. But internaly EJBs make use of JDBC calls to access databases.
So the answer of your question: if your application is making lot of database calls, with small application user base and non EJB experienced developers, go for JDBC. Else go for EJB.
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
I would go with EJBs depending on the app server u are using.
Please give a reading of Core J2EE patterns book to decide by yourself.
But as a long term solution it is preferred to use EJB in combination with JDBC(inside EJB u have the data access layer which uses JDBC).

SCJP, blog
Riaz Mohamed

Joined: May 31, 2002
Posts: 23
hi all,
I guess jdbc would be real fast and if you do have a situation where u query or insert into multiple tables jdbc i guess would be the best to use . As said earlier you could use jdbc with jta for transaction management. Well the major performance issue would be ideally if u had a query of more than one table then u gotto have many ejb's each for a table in the database ,and the more ejb's u have the lookup from your session bean would be more costly.Sope i would suggest you go for jdbc though ou would not get the sturdiness , maintenance and security you get with EJB
Randy Motluck

Joined: Jul 19, 2002
Posts: 10
If you go with Entity EJB's and CMP, you don't do the SQL (in an IDE). If you go with JDBC, you may need to write SQL that is not portable from DB to DB.

Just an extra 2 cents.
I agree. Here's the link:
subject: EJB vs JDBC
It's not a secret anymore!