I am working on my graduation proposal.

A friend of mine works in the IT industry. I discussed with him about my proposal, and here is what he told me.

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 entity bean 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.

So I want to use a demo J2EE application provided by Sun called "pet store" which most of you know.

1. I'll run the original pet store application, test its performance, and record the data.

2. Change that version of the application by replacing the entity beans with JDBC, and run it, test its performance and record the data.

4. Then I can create plotted charts and compare the performance of the two versions and may get a conclusion such as "EJB entity bean access of database is slower than JDBC".

At this moment, I think it's a very interesting project. However, I need to figure out if this is feasible. What do you gurus think?

Hello

Entity beans are most costly resources ,Only used when
you database table is particiapating in multiple and complex transation ,if you are reading data then go for JDBC and Session bean.

Most of the EJBS projects were scrapped ,as they dont know what for they are using EJBS.


Hope this help you .
Cheers -M

Hi Gene,

Keep in mind that the PetStore was written as more of a educational example, than something that will perform blindinly fast.

It shouldn't be too much of a problem to cut over from BMP to straight JDBC. You will probably want to encapsulate the JDBC code into separate beans and not have them coded directly into the session beans - this will allow you to re-use the JDBC code amongst SB's and also cut down on the amount of changes you will need to make to the SB code.

Entity Beans will not perform as well as straight JDBC calls. That much is completely undeniable as, at the end of the day, entity beans make JDBC calls themselves. Where you do get benefit is from the in-built transaction, security and scalability that you would have to code by hand if you code your own JDBC calls.

An interesting side to your thesis may be to look at how much container managed persistence will save in development costs as opposed to the performance benefit that you get from JDBC calls. From my own experience, CMP's are definaltely slower, but the time we saved on development (and we had a large number of tables to model) was well worth the performance hit.

Upload your results when you are done, it will be interesting to see them.

Good luck,
Darren.

I'm not so sure it's black-and-white. One situation I have found where Entity Beans work well -

I have a database that's producing the major bottleneck in the system. We can scale up the cluster by adding more appservers, but it's not so easy to scale up a really busy database. Most of the database activity is reading information. Updates are relatively rare, and are performed by administrator-type people.

In this case, I used read-only entity beans, to take some of the load off the database. This is at the expense of extra work on the appserver, but in this case, it was worth it.

Read-only entity beans aren't part of the J2EE spec right now, but I understand that many appservers support them. And I have heard that they are seriously being considered for the next EJB specs.

I have to agree with all the replies. EEJB is ALWAYS slower. For instance, on our system, just to load up 1 Entity, you have to perform 2 hits:

1) findByPK(123456)
2) ejbLoad()

If you use Value Objects, and know in advance you want to load this object, all you need is:

select * from table1 where pk = 123456;

1 hit. BUT! You have to code this stuff yourself. Now imagine you got 50 or so classes. And debug. And maintenance. CMP of EEJB makes it automated, and for only $5000/CPU you can even get a nice GUI tool to do it with. Sure it is a little slower at runtime, but it is worth it in many cases. Especially in development costs, code change management, and where caching is key. The hard part is deciding what works for you.

As far as your conversion, all you have to do is recode the EEJBs as VOs and add your own JDBC queries.

Greg
http://www.hotscifi.com