Can anyone tell me what's the disadvantages when using Entity Beans. Thank You:)
Just a few:
- You need, at least, one experienced EJB developer to get it right from the beginning of the project.
- Performance! Transaction, concurrence, and security support has a penalty.
Can you or anyone else elaborate more about this topic??
The main disadvantages about EJB is that if you don't know how to use them properly you'll shoot yourself in the foot.
Also, you have the complexity to setup a simple EJB (3 classes and 1 descriptor, minimun), but this can be aliviated using code-generation tools.
Besides that, I don't really see any disadvantages. Distributability don't cause any performance penalty if you're using EJB 2.0 with local interfaces. Even in EJB 1.1 most of the mainstream app servers use local calls to EJB when made inside the same JVM. Performance is not an issue neither, if you do the things the right way (as is usual with performance).
So, I guess that the answer is "Complexity"
If you wonder about the EJB performance, remember that TSS use them (and the traditionally slowest form of entity beans, the BMP), and they where /.ed during the J2EE vs .Net Petstore debate.
Even with local interfaces, calls to entity bean (or any type of ejb) methods declared in the local interface have to traverse the "J2EE stack" - ie that piece(s) of code implemented by the ejb container that deals with transactions, pooling, caching, security etc.
This is significantly less performant than direct java method calls.
Some app servers implementations are quicker than others, also some 3rd party vendors have implemented non standard techniques to avoid the stack. (eg mvcsoft)
So often entity beans are kind of overkill when plain java objects might do very well. Especially when you consider most people use session beans exclusively behind a session facade, thus making the ability to declare your secure and transaction settings on a method level more often than not (IMO) used in the majority of set-ups.
We are using entity beans, with local interfaces and vendor specific "hacks" to improve performance, and our system does perform well, so a well designed entity bean system using the right techniques and tools can work.
In the coming months and years I would look towards JDO as an alternative to entity beans as it seems to avoid a lot of the above issues.
Anyway, just my 2p
Something that strikes me funny is that JDO are more or less EJB without security and distributability... Caching is optional in both worlds but I bet most vendors will put it for performance reasons.
That said, the problem with direct java calls is that of entity synchronization: If to objects reads the same information from the database, some other objects use it and modify it and write it to the database, some change will be lost, becasue we are working with different instances of the same data (thats a long know problem in DB programming). This gives you the need of transactions and entity sincronizations, both are given by Entity BEans and JDO. And pooling is used to reduce the object creation explosion, increasing performace (from the GC point of view). This is provided in both JDO and EJB.
Also, for use JDO you don't need to use JNDI (big gain, that comes from the lack of distributability).
Where JDO really shines is in the queriying mechanism, and as I'm a EJB fanatic hope that CMP Entity Beans cach up :)
"becasue we are working with different instances of the same data (thats a long know problem in DB programming)."
It's not really a problem. It is perceived and promoted as a problem by vendors to sell more worthless crap like O/R mapping tools.
Any data-syncronization "problem" can be solved without the use of some, over-priced data access tool.
I agree. ejb ql currently is a joke. EJB 2.1 addresses some of these issues but it is still lacking in so many areas. To do anything useful you have to rely on container extensions.
I know a couple of use patterns where Entity beans are not sutable:
1. Massive (bulk) inserts/updates. You can hit bean cache limite very quickly. Plus there will be a big overhead in keeping object representation of the database objects.
2. Complex finders. EJB-QL is no use for this situation. For instance if you have let say this SQL for finder:
from ACCOUNT, BALANCE, CUSTOMER, PARAMETERS
where ACCOUNT.ID = BALANCE.ID
and BALANCE > 2000.00
and ACCOUNT.CUSOMER_ID = CUSTOMER.CUSTOMER_ID
and CUSTOMER.NAME LIKE "%Doe%"
and (PARAMETERS.LAST_VISIT > 10-10-2002
or 1 < (select COUNT(*) from TRANSACTION where TX_DATE > 10-1-2002))
order by ACCOUNT.ID, BALANCE.BALANCE
you's hardly be able to imlement it to via EJB-QL while this type of query is very common in real apps.
Bottom line: All these problems easely resolved by wrapping direct or DAO SQL call into SLSBs.
You're right, those are the case that Entity Beans are not the way to go... perhaps. You will never know without testing it first...
BTW, do you notice that the query you put to "prove" that EJB is useless, makes no sense? Just look that you're using BALANCE>2000.00 as a condition, but BALANCE is a table... Also you're crossing 4 tables but only expressing the relationship between Account and Balance, and Account and Customer.... I hope that you're typing in a state of rage and where not thinking what was flowing throught your fingers...
Just for the records, we manage to replace a complex querie that looked more or less like that one (with the difference that this one make sense and actually worked) with simple queries and some processing at application side. Later we replace the simple queries with finder methods from EJB and the stuff actually ran faster than the query...
As usual, you can be sure of anything until you test it. Specially in an area with so much FUD, buzzwords and countered positions as the EJB world.
>2. Complex finders. EJB-QL is no use for this situation. For instance if you have let say this SQL for finder:
And, frankly speaking, in most large-scaled projects the 40%-60% of the queries are complex. So, the use of entity beans becomes a doubtful option on a large-scaled projects.
How did you get that number(40%-60%)? (just curious)
Anyway, Complex queries appear for two main reasons:
1.- There is a higher order relationship (3 or more entities related), which involves the join of more than 2 tables. These can be VERY lengthy and somethimes doing consecutive simple queries (at most 2 tables), storing them in temporary tables (or views) and processing them is faster.
2.- You're trying to do in a query something that is better done using an algorithmic approach.
Also, most complex queries are nearly "write only", meaning that you can only write them but are very difficult to modify them.
In both cases a store procedure is better than use a single query. And everything that can be done in a SP can be done in Java.
The choice of what you prefer is yours.
How did you get that number(40%-60%)? (just curious)
From practice. In four large-scale projects I took part in the number of complex queries varied from 40% up to 60% of all queries in the systems.
>In both cases a store procedure is better than use a single query. And everything that can be done in a SP can
be done in Java.
Yes it can be done, but Java will never be faster than database, that's the fact. Actually, the best projects differ from good ones that in the best project you've an optimal distribution of your business logic between database and middle tier, rather than in good ones this distribution is either on one side or on another.
Your database is a powerful tool and it's no good if you don't use its abilities just because you've gat a tool that is easier in use but not optimised at all for the operations you perform.
One of my points didn't make througt the rest of the message, and have nothing to do with EJB or Java. Let me state it again:
Most of the times you can replace a complex query with an algorithmic aproach, like Store Procedures (I added java, but let stop here as that's another point)
Don't misinterpret me. I'm not agains using store procedures or using all the power a DB can give you. I'm against using it "for the sake of it", the same as I'm against using (or no using) EJB "for the sake of it". Sometimes the benefit of not having any business logic in the DB (as in our current project) outweight the performance increase from using SP (we actually benchmarked it, our application don't benefit much except in batch updates, for which we're planning to do a loader that use every single DB trick at our disposal to optimize the response time), sometimes it don't.
I guess that what I'm trying to say is "don't use the tool for the sake of the tool"
Of course, I'll continue defending EJB (all of them) for some domains because they worked very good for me ;)