I talked about this with a friend of mine who works in the IT industry.
He said that access to database by EJB entity bean can be very slow, and JDBC performs much better. He says that's why his company does not use EJB at all, they use JDBC to access database. And he also mentioned that they selected JDBC because it supports multithread better and that there will be some multithread problems if we use EJB entity bean.
He said we have a pet store demo application from java.sun.com, which I think most of you know.
So he said that I can run the original pet store demo application, test its performance, record the data, and then change that version of the application by replacing the EJB stuffs there, and run the latter, test its performance, record the data, and then I can make a good comparison between the 2 versions and may get a conclusion such as "EJB entity bean access of database is slower than JDBC".
What do you people think? Is this feasible? And is it optimistic that I'll get anything from such a comparison?
If your answer is yes, I'll start to work on it. At this moment, I think it's interesting.
Thanks a lot.
For EJB's persistence speed has a lot to do with the Application Servers implementation. They are using JDBC to access your data, and they are creating the code underneath, so you don't have to.
So in one camp the argument is, Who writes better JDBC code, you are the App Server Vendor? I would hope the App Server Vendor, since it's their business.
Another argument is EJB containers can not handle relational data very well. meaning when you have two related tables it doesn't have the "Objects" it needs to handle it. No two commit transactions or Objects that describe the realtionship, and in order to do it you need a third party tool like a "TopLink".
In an EJB container you have connection pooling that is very optimized by the vendor, whereas in your JDBC code yourself you will have to either create your own pool, which you have to maintain. Or create Connection all over the place and that is expensive.
Also you will have a lot more coding to do in JDBC alone for your classes, and that leads to maintenance questions, scalability in your design, and other possible risk areas.
Whereas EJB's the App Server and Container handle a lot of these for you, and if the App Server adheres to the standards you are good.
So you decide.
Oh and check out The ServerSide Site. I am sure they have had this debate many times in their threads there.
Good Luck in your class.
[ May 16, 2002: Message edited by: Mark Spritzler ]
Originally posted by Mark Spritzler:
[QB]I know, and it is really tough to find someone who is an expert and really knows this answer. That would be the only reason why I wouldn't go EJB is the infancy of the technology. We tried it at our work, and it didn't work, but not because of the EJBs but because of Reporting, and finding good people.
I agreee wholeheartedly. We had the same problem here 6 months ago. Inexperienced EJB programmers with large over head on the EJB side. Took awhile to narrow it all down but it was more due to the fact that they programmers didn't know how to implement the Entity Bean model properly.
The one thing to understand though is that the inherit reflection needed doe the app server to do all that code for you (in the case of CMP) will add overhead no matter how good the yours or the app servers JDBC code is.
We did a lot of testing to prove this and now what we 'usually' do is use the "fast lane reader" pattern to get lists and info that is read only by using JDBC directly to the database. When we need the transactions, security and isolation of the container (and don't want to write our own custom model), we use the CMP/BMP model for Entity Beans.
This has been successfull performance wise for a large ERP application running the EJB 1.1 specs and I suspect it gets even better when you move into EJB 2.0.
You'll see that it is a very fine balance of 'when to use what' to get the best performance for the least headaches on your system.