Can anyway one tell me why and when someone should go for an entity bean and when not. I think almost everything can be done with the help of a session bean like database inserting, deleting etc.. Then what are the critical factors ,that depends for chosing an entity bean.
Thanks in advance
An entity bean represents a persistent storage, normally a database. When the EJB container terminates, the entity state remains in a database. And it can be shared for several clients.
A session bean represents only one client, it's no shared,
performs a task for a client. It's no persistent, when the client ends its session bean is no longer available.
Thanks for the responding. Now correct me if I am wrong, I think we can make the session bean also persistent by writing code in it, virtually a type of BMP. What I mean is that what ever modification I do the same thing can be reflected in the database by using jdbc statements in my code.
So why entity...
Thanks in advance.
You can use jdbc statements and sentence SQL in the code of a Session Bean, but with th Entity Bean you forget about all this work, with Entity you don't have to code it. In a Entity Bean you can specify methods to find in the database and only you have to map in the deployment descriptor the fields of the table of the database and only write one line to define the find method. Entity Beans model data and Session Bean handle the business processes. Have you read the book Mastering Enterprise JavaBeans? Dowload it, it's very useful and clear, and it contains examples that let understand better the concepts.
Moreover entity beans can survive server / container crashes, so your data is much more safer to be with a entity bean rather than a session bean.
if you are using session bean, you can still survive container crashes, but you need to rely on clustering and you will have to decide on how many servers will be clustered.
Entity beans also provide better scalability. Thats because most app servers ( I use Weblogic) have parameters in the deployment descriptor which specify how many beans can be cached and in how much time they will timeout. An judicious use of these parameters lets u pick up the entity beans from App server cache instead of making a round trip to the database which involves network latency. The performance gains obtained are in several orders of a magnitude if yours is batch app or a lot of customers hit on your site at the same time.
Thank you Poli, Vijay and Sameer for your responses.
I now somewhat, get the picture as to why entity beans are used .
a)It saves us from writing extra code(The bean does all the internal mappings for us. ok some time can be saved.)
b)surviving server crash. -
But what does the session bean got to do with clustering, as the session will be writing to the database on every invokation.
c)cashing values in the bean so that it saves a trip to the database.
But suppose the value in the database is modified by another application , then it wont be reflected in the bean. So Entity bean can be used only in situations where only that particular Entity bean can change or modify the database and no other application has a hand in it.I hope you get my point.
Clustering is going to be helpful only in the case of Stateful Session bean.
Suppose i've stored the temporary items added in a stateful session bean. Since my session bean is clustered and uses in-memory replication, i can have my client access the session bean in the second server even if the first one fails.
This way i provide my client with the same data from the session bean even in the case of failures.
I have heard though i havent tried this, Bea Weblogic 4.5.1 does not support statefulness of the Stateful Session Beans with clustering. In other words a failover occurs on a stateful session bean state information is lost. I have further being told by an expert that this is also a law laid down in the spec as the spec says in case of a stateful session bean the same session bean object needs to be resued which means that u cant use a replicated copy.
Could u please throw some light on this as the alternative of perserving state in a HttpSession is inelegant and defeats the purpose of using Stateful session beans in the first place.
with weblogic 5.1's sp 6 you can get back to the same bean which is replicated in another server. since the replicated instance of the bean is same as the original bean, and the handle would work even in case of failures.
But with weblogic versions < 5.1 you can only use the home to recreate another stateful session bean in the case of failure.
Every response here gives a good opion why we need entity beans.
I have mine here.
Going deep into the blueprint of J2EE, it's not hard to find the SUN's vision on enterprise computing. Its model basically consists of three layers, which I believe everyone knows by their heart, presentation, business logic and business data. There is nothing new in it. J2EE is a model, e.g. it is abstraction of the way enterprise applications should follow according to SUN. Business data will be persisted into DBMS. But does it care which one? Not at all! Because the model views it as pure data. You can write your beans free from any DBMS until you deploy them. It makes software vendors' life much easier when their clients pick different DBMS as their data store. (I heard that Oracle had a few hundred people worked on porting their DBMS to different platform.) And if your boss wanted to switch to another DBMS, which has a world of differences from the one you deployed originally, wouldn't you love the entity beans you developed when all you need to do is hook the application to the new DBMS without making a line of code change?
J2EE provides a generic solution. All the business problems don't have to fit into this model. And I still hear people asking how the parent-child records implemented in entity bean.