I know Entity Bean consume lots of resources, and I'm told not to use entity bean if I just want to insert or retrieve data from database. but could any one here give me any good example of scenario where Entity Bean is suitable to use?
Entity EJBs 2.1 is OR mapping as JDO, TopLink or Hibernate. Entity EJBs can be implemented also by above mentioned frameworks.
You should use OR mapping as the DB cache. Small amounts of data accessed more times. E.g. you have a table, which will never grow more 100 lines and these table is accessed very often. It is good idea to create 100 OR mapping objects and keep them in memory.
With OR mapping you have to avoid to create big amounts of OR mapping objects encapsulating a DB data. E.g. you will select 10 millions lines from DB table, you will create 10 millions OR mapping objects and traverse these JAVA objects to count them. This will definitely kill your performance and scalability.
In this case you should go for SQL (JDBC or OR mapping features (e.g. Entity EJB select/find methods)). If SQL is not suitable you can go for stored procedures (but only exceptionally for e.g. performance reasons).
Use DAO to encapsulate different persistence strategies (OR mappings, JDBC frameworks, Stored procedures), so your business logic will not see any implementation details.
I don't agree. You can implement the "count" service as a home method, and implement that method through JDBC; all of it withing the EJB spec. You don't need to implement it with a findAll() method and getting the size of the collection. Why would you do that?
Cheers and happy coding,
You don't need to implement it with a findAll() method and getting the size of the collection. Why would you do that?
I wrote you should avoid that. Maybe I used a stupid example ...
Argh! My bad, then. Sorry.
Entity EJB, or any O/R mapping technique, is a convenient abstraction that provides a reasonable performance tradeoff when your application typically works with one object at a time (customers, orders) or a small number of objects at a time (a customer's addresses, an order's line items).
Performance tends to become more problematic as your application needs to deal with larger collections of items at the same time (say, you're paging through a list of a million customers). Various O/R mapping systems have different strategies for handling the problem. In many cases you can overcome the performance problems or at least, reduce them to the point where the benefits of O/R mapping outweigh the performance issues.
I built a straight-up EJB entity bean application some years ago which is still running today. I was able to get it to perform reasonably well after spending a fair amount of time adjusting the XML configuration files. On the other hand, my app typically deals with sets of less than ten entities at a time, and never more than a few hundred.
Entity beans have gotten a pretty bad name due to performance problems. But on the other hand, all of Java is slow compared to C or assembly language; we write in Java for its productivity benefits, not for its runtime execution speed. So it boils down to how important performance is to you compared to other concerns.