This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes EJB and other Java EE Technologies and the fly likes Why Entity bean is not used ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Why Entity bean is not used ?" Watch "Why Entity bean is not used ?" New topic
Author

Why Entity bean is not used ?

R K Singh
Ranch Hand

Joined: Oct 15, 2001
Posts: 5371
I might be wrong but I have seen projects where Session bean is used and Entity bean is not used and instead of Entity bean, DAO(Data acess object)s are used ?
Why Entity bean is avoided ?


"Thanks to Indian media who has over the period of time swiped out intellectual taste from mass Indian population." - Chetan Parekh
Ram
Ranch Hand

Joined: Apr 07, 2003
Posts: 43
Originally posted by Ravish Kumar:
Why Entity bean is avoided ?

Below are the list of scenario where you may have to avoid using entity bean,
1) Loading whole bunch data in to database in one shot is very very inefficient when done using entity bean.
2) Rearly used data should not be repesented as entity bean.
3) When you have a production enviornment with multiple appln servers and they are not clustered DO NOT USE entity bean.
4) If your application always need the excat copy of the data in the database, using entity bean is
not good solution.
I may have left few others ...
If your application involves, for the most part, one of the above scenario usage of entity bean should be avoided.
[ April 25, 2003: Message edited by: Ram ]
Geeta Ramasami
Ranch Hand

Joined: Mar 05, 2003
Posts: 72
Hi,
I don't understand one thing here.It is mentioned that "If your application always need the excat copy of the data in the database, using entity bean is not good solution".
In entity beans only the callback methods (ejbLoad() and ejbStore())ensure that the data is always in sync and u work with current copy of the data..
Cheers
Geeta
Ram
Ranch Hand

Joined: Apr 07, 2003
Posts: 43
Originally posted by Geeta Ramasami:
Hi,
I don't understand one thing here.It is mentioned that "If your application always need the excat copy of the data in the database, using entity bean is not good solution".
In entity beans only the callback methods (ejbLoad() and ejbStore())ensure that the data is always in sync and u work with current copy of the data..
Cheers
Geeta

You are correct, if we assume that your application is the only entry point to the database. But in real life this may not be true.
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Ram:

Loading whole bunch data in to database in one shot is very very inefficient when done using entity bean.

This was known as the N + 1 problem, since it took N + 1 database calls to load N Entities. Furthermore, this is no longer a problem with the majority of CMP implementations. Most CMP implementations optimize this into a single database call.
Originally posted by Ram:

When you have a production enviornment with multiple appln servers and they are not clustered DO NOT USE entity bean.

Why? I don't see any particularly distinctive disadvantage to using Entity Beans in this situation.
Originally posted by Ram:

If your application always need the excat copy of the data in the database, using entity bean is
not good solution.

The default behavior of Entity Beans is to reload from the database on every access, which is one of the reasons people complain about the performance of EJB. Most containers provide additional caching levels to optimize Entity Bean access, however it is not necessary to use these features.
See this thread for another recent discussion on the merits of Entity Beans.
Ram
Ranch Hand

Joined: Apr 07, 2003
Posts: 43
Originally posted by Chris Mathews:

Why? I don't see any particularly distinctive disadvantage to using Entity Beans in this situation.

If the you have two servers that aren't clustered there is a possibility that one server have dirty copy of a bean. In that case we will be forced to call ejbLoad every time a database operation is performed, which takes away a major advantage of using entity ejb, caching.
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Ram:

If the you have two servers that aren't clustered there is a possibility that one server have dirty copy of a bean. In that case we will be forced to call ejbLoad every time a database operation is performed, which takes away a major advantage of using entity ejb, caching.

This problem is not unique to Entity Beans. It is a problem with any persistance service that is not using a distributed cache. How does not using Entity Beans solve this problem?
Ram
Ranch Hand

Joined: Apr 07, 2003
Posts: 43
Originally posted by Chris Mathews:

This problem is not unique to Entity Beans. It is a problem with any persistance service that is not using a distributed cache. How does not using Entity Beans solve this problem?

You are right. My arguement is you shouldn't use entity beans if your application happen to fall into the mentioned scenerio.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15960
    
  19

The whole Session Bean vs. Entity bean argument can easily start a religious war. In times past Entity beans, especially CMPs, were of limited utility and Session Beans were much more important. Because Entity Beans are simpler when all you really want is a data access object, a lot of work has gone into optimizing them in order to allow better control over efficiency and currency.
I tend to use more Entity Beans - and fewer Session Beans - than most because most of my business and pre-presentation logic is in Struts Actions and I have direct control over the source table formats. For me, Session Beans are good for:
1. Logic that's shared outside of the limited context of a single application.
2. Transaction-controlled business logic
3. Creating fa´┐Żades for data resident in several different types of Entity beans (if CMP 2.0 can't handle it cleanly, simply and in a way that performs well).
4. Anything else that would look good as an EJB but is primarily process-oriented. It's not good practice to put business logic into data objects. Sometimes the business logic changes even though the data format doesn't.


Customer surveys are for companies who didn't pay proper attention to begin with.
Pomodoro Linguini
Greenhorn

Joined: Apr 28, 2003
Posts: 3
What i would like to know is when to use entity EJBs?
Above mentined reasons cover just over 85% applications anyway.
R K Singh
Ranch Hand

Joined: Oct 15, 2001
Posts: 5371
Originally posted by Ram:
You are correct, if we assume that your application is the only entry point to the database. But in real life this may not be true.

But as per "Mastering EJB 2, Ed Roman", even if some other application changes the DB, Entity beans will reflect latest changes made in DB.
I think, this particular reason should not stop us from using Entity.
Please correct me if I am wrong.
R K Singh
Ranch Hand

Joined: Oct 15, 2001
Posts: 5371
Originally posted by Tim Holloway:
Because Entity Beans are simpler when all you really want is a data access object

I heard that, use of Entity bean makes server heavy. I mean, entity beans take lot of memory over the period of time.
Any expert ??
TIA
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why Entity bean is not used ?
 
Similar Threads
local interfaces --- PLEASE HELP !!!!
What is saved during EJB Passivation?
Session vs Entity bean
Container Managed or Bean Managed
Why relationship?