I understood that we have a lots of discussion on this topic already. However, after I read thru some of the discussions and documentation. it made me even more confused how,when, why should we use Entity Bean?
1) In EJB 1.1, it said that entity bean should be a "coarse-grained" object, which is fine with me and which is what I have implemented so far.
2) In EJB2.0, we can implement fine-grained object as entity bean. Should we do it?
3) People started talking replacing Entity Bean with JDO.
4) In weblogic documentation, it stated that even though a coarse-grained object, we should not implement it as an entity bean unless there is added-on value.
5) I have read through the chapter "Intro to Entity bean" by Ed Roman stated "Entity beans, on the other hand, contain core business data, such as product information, bank accounts, orders, lead tracking information, customer information, and more"
For example, I have a domain object called "location", it is a very simple object with 20+ fields. Should we model it as an entity bean? from #5) it shoud be an entity bean but in #4) it should not be an entity bean.
Any hints and tips will be very appreciated.
Just 2 quick comments:
>>In EJB2.0, we can implement fine-grained object as entity
I believe the reason for this is the possibility of using local interfaces in EJB 2.0 (the cost of making fine grained local calls is fairly cheap).
Also, I thinks its generally recommended to use JDBC directly if you are not performing any updates/inserts (especially if you are performing joins).
If you are still worried about issues like performance and technology familiarity go with JDBC........... you already know it.
If you can get over these issues and are interested in learning a technology which is pattern and standards driven go for J2EE...........
J2EE works a treat..... as long as you know what your doing..... be prepared to learn lots .....
From my experience the more you know about J2EE the better this technology gets.
I use BMP entity beans using Agregate pattern under the following scenario
- Coarse grained, closely modelling business entities
- The underlying data is not updated by any other application or bean, so that I can use use Commit Option A for getting improved caching benifits
- With the Agregate pattern I keep track of updates for the dependent objects, so that at the transaction commit time I don't have to save the whole object hierarchy in the database.
Hope it helps.
you are viewing several discussions all at once, and so have seen 'do coarse grained', 'do fine grained'. And your title of when to use EJB or JDBC is yet another argument.
Both fine and coarse grained beans are design patterns in their own right.
The session facade idea is to have a stateless session bean implementing coarse grained business logic, and this makes use of fine grained entity beans. The stated advantages of this are that the fine grained beans (ie 1 EJB per table) are really good candidates for code reuse. They remain 'pure' and can often be auto generated.
The business logic (eg roll up a years records and store an audit report...or whatever) can be stuck in a stateless session bean. This code has the usual middle tier benefits but need not worry about data reload on rollback (because its stateless) and is NOT a good candidate for code re-use.
I prefer session facade and fine grained entity beans over coarse grained entity beans. It's an obvious, clear decoupling of database activity and business logic. And it allows code generation. On the other hand I haven't had to do much bulk update of multiple tables....
Which is best? Both are good, but fine grained + session facade is a bit more modern as a pattern - because of all the code generation you can do.
Do a careful evaluation, then flip a coin and you will be fine.
ps I ignored the EJB v's JDBC question.... sorry.
The agregate stuff can become a nightmare. The idea here is that you have a bean holding other beans. Eg a person agregates all of employee, address, department tables - and thus EJB's.
The issue is about moving the data to the client where some of it is updated (eg the address), and then you want to store it. What is stored? Do you write it all back, do you have value objects which also agregate other value objects and track changes? Does you EJBStore for person recognise the audit data and only write back the agregates that have updated?
The answer is probably yes to all of the above, otherwise its really inefficient. Which means you are basically writing your own object graph persistance database/cache - ie it works at the client, can be serialised and persisted.
And then you have to worry about dirty data and transactions and ..... (brain explodes).
Aggregation of this type is quite a heavy architecture.
Fine grained entity bean that simply maps a database row is a nice ideal, but in real world applications it affects performance. The only benifit in this case is that it encapsulates the database schema.
So I don't use entity beans, unless there is some added value in terms of caching dependent objects etc. and when they map closer to business entities. I also use session facade. The SLSBs access the database directly or invoke coarse grained entity beans.
It's not just me. There is a general trend not to use entity bean, unless there is a strong reason for using it.
"There is a general trend not to use entity bean"
Every vendor recons that they are slow and should be used with care, i.e. only when their is an obvious benefit. Such as when you want experience for your CV.
And, we are about 8-12 months from the 4GHz PC. So who cares. EJB's are not twice as slow, so choose them if you want and in a tiny while they will run faster than ever before, the wonder of hardware.
To much truth on a friday afternoon is not a good thing.
Thank you for all your feedbacks.
Actually, i would like to know what persistence layer should we use and feedback from you. I have been doing EJB1.1 with Toplink. Eveyone knows that the CMP of EJB2.0 is very different from EJB1.1, and my question is what will CMP be on EJB3.0? Also, lots of people talking about replacing Entity bean with JDO. Will it be a good idea? or should we stay away from entity beans for now or use JDBC?
Performance is an issue but not a crucial one and Jon has mentioned that hardware will solve this problem eventually and good design can help it out too.
Thanks again for all of you.
"And, we are about 8-12 months from the 4GHz PC. So who cares. EJB's are not twice as slow, so choose them if you want and in a tiny while they will run faster than ever before, the wonder of hardware."
Faster hardware is nice. But it should not be looked at as a crutch for sloppy design decisions.
If you are happy with entity beans, stay with it. But I hope you are keeping an eye on unnecessary calls to ejbLoad() and ejbSave() by your container. Also, I hope you are not using ejbFindByxxx() that returns 10000 remote objects.
faster hardware is a great way to make many decisions redundant, and it is the basis for almost every architecture currently in existance. Especially J2EE.
So I would suggest that the in the last 10 (maybe 15) years we have finally gained a 2GHz increase in performance for PC's. In the next YEAR we are going to gain a FURTHER 2 GHz in performance.
Laugh all the way to any design you like.
OK, I'm overplaying it a bit, but the truth is that we are getting more power than we know what to do with. Which leads us to java and then to app servers and J2EE....
"If you are happy with entity beans, stay with it. But I hope you are keeping an eye on unnecessary calls to ejbLoad() and ejbSave() by your container. Also, I hope you are not using ejbFindByxxx() that returns 10000 remote objects. "
we use fairly fine-grained objects with a stateful session to manage connectivity to clients, and then a number of different stateless session facades which manage business logics.
fine grained beans in this architecture are heaps faster to develop than coarse-grained beans. also, developers are much more expensive than hardware.
but the statement above is a way to bring is back to the original question: when to use entities vs jdbc.
yep, in the session facades, instead of using a findByXXX() method in the entity that returns 10,000 objects, we use findByXXX methods in the session, using JDBC, to return those 10,000 value objects. well, not 10,000 because in our application that number is a little overdone for the data, but on the order of hundreds. we find it has acceptable performance.
typically in our application the user will view a list of eg 500 objects, select one, and modify that single object ... which we do via the entities rather than JDBC.
so there's an answer to both questions.
What is the benefit of using an entity bean to do an update of 1 object rather than just doing a standard jdbc update through a dao or something like that? Doesn' the entity bean have to do a select, then an update, where the DAO could just do an update?
The advantage is that you don't invalidate the EJB cache of the app server.... But then again, the app server does an ejbLoad before every call anyway (unless marked to load very infrequently)....And we want this, and we want cmp..hmmm.
OK, so the full picture is
1:jdbc for bulk selects, return the data to the user, he updates one, your biz logic uses JDBC to store.
2:jdbc returning bulk selects, return the data to the user. He then uses an ejb (ie BMP, select, update) to persist
3:session bean, fine entity bean, findBy which does bulk seleck of pkeys and then individual selects based on these (if you have a really crap app server - see fat keys elsewhere), to return the data. Then an ejb (select, update) to persist.
Point 3 is the real interesting one, because its the one the app servers all try to optimise. And the entire point of EJB is to cache objects in memory and so optimise init times, and yet have really crappy ejbLoad/ejbStore cycles for every call. Unless you say to the app server that the data is only ever altered by the container and its cached versions of the data are always valid.
So the best case for pt 3 is: ap server bulk loads ejbs, and has loads of memory to hold them in. These ejbs are available for access and store without going to the DB, accept once in a blue moon. Hurray! we have an in memory db cache. BUT, what about complex selects? These must run against the db, BUT they only need return the pkeys, which are then checked against the in memory cache, so only needed ejb's are loaded.
Right. The answer is, if you trust your app server and have tons of memory for ejb cache then its faster as the data is ALREADY held in java classes, and this is ideal for a java programmer. Even the DB cache will not be as fast because jdbc must still do data conversion.
For this to remain true then all FindBy methods should be CMP, so that the container can search the in memory pkeys and reuse beans whenever possible.
But what of clustering? Say you cluster with one master and one slave per bean, then every change must now be replicated. What is the overhead of this when its in Java as opposed to binary (within the DB), and when does it happen with large transactions?
Is a high level java cache better than a low level DB cache.
I think that we are going to try and go with a combination type solution... Tables that will be updated frequently will be fine-grained cmp beans. Everything else will use coarse grained DAO's. All data will be transported to the client through compound Value Objects. I have implemented what I call a Value Object Manager (Proxy/VO Factory) to the Data Access Layer. The client goes through a proxy/facade to the Business Objects.. The Business Objects go through the Value Object Manager(Proxy) to the Data. I will be doing some extra Value Object caching at this point to improve performance. I called it a Value Object Manager because it acts like a VO Factory, Proxy, and Cache Manager. Its not as polluted as it sounds.. lol
I would like to use Entity Beans as a caching mechanism for coarse Business objects that do not change very often, because we have a performance problem.
But the Entity Beans very often passivate and then perform an EjbLoad() even though the isDirty flag is not set to dirty (We are using Bean managed persistence).
The EjbLoad() all the time is causing to much database load.
What can we do?
Thanks, Karl, firstname.lastname@example.org
ejbLoad() has nothing to do with the dirty flag. Unnecessary calls to ejbLoad() can be prevented if you select the commit option A, for example, by using
db-is-shared deployment descriptor in Weblogic.