Search for Entity beans

[Hui Ge]

If my J2EE application does a search for a list of all Users in the system, (Users implemented using bean managed entity beans) and there are a million users won't the system created a million instances of users and cause a great strain to the system and hence response time?

If this is true how can i overcome this?

[David Harkness]

Typically the total number of entity beans the container will load at once into its cache will constrain this before you exhaust your memory. If you truly need to perform an operation on all users, you'll need to find a way to break it up into chunks.

[Valentin Tanase]

Hi Sing,

You have pretty good chances to get OutOfMemoryError(s). You definitely need to run several load tests in order to make sure that your application works. This will help you to set the JVM by allocating enough memory, tuning the garbage collector, etc. It might also lead you to the conclusion that it will never work for the load your application was designed to support and this might force you to come up with other design strategies. The simplest one I could see is to turn to database for help. Most of the databases allow you to set the maximum number of rows returned by each query. Setting this parameter to an optimal value might be an acceptable solution (if your users will agree that a query which returns one million rows is useless anyway). The major drawback of this solution is that all applications using the same database will encounter the same limitation.
Regards.

[Bhiku Mhatre]

Hello Hui Ge,
The choice of Entity bean is misplaced here. Entity bean, is not suitable for data mining like operations. You are better off using DAO or POJO/JDBC combination here.
But if the application is implemented, as suggested by Valentin adn David , Check the performance.

Regards
Bhiku
[ March 17, 2005: Message edited by: Bhiku Mhatre ]

[Hui Ge]

Hi all, thanks for the response. Please correct me if i am wrong.

I thought entity beans will have the latest information, that is their information may not have been updated to the database yet(at the mercy of the container) thus using a DAO/JDBC to retrieve information from the database directly might pose a problem.

[S Mithal]

Entity bean and database data is ALWAYS synchronized for client access. The container will take care of this by calling ejbLoad() and ejbStore() whenever required. Entity bean is a good choice when you need to update a few rows in the db often, but not a good choice for query/search. You should be using JDBC for Reading. However, in your case with a million users, it makes no sense to retrieve their list. Entity beans are not suitable for OLAP data retrieval and you shud use the db vendor specific tool for this. For example, if your database is Oracle, you can write a client using Oracle OLAP API to perform this function.

[Hui Ge]

Dear S Mithal, thanks for the informative response. Am i right to say that any changes made to entity beans is immediately synchronized with the database?

[Valentin Tanase]

Hi Hui,

Am i right to say that any changes made to entity beans is immediately synchronized with the database?

Yes and no. No because they are not committed immediately and yes because you�ll always get the latest data (supposing you�re using the right transaction isolation level). Actually it works like this: the container calls the ejbLoad when the transaction starts and it calls ejbStore before committing the transaction. A very simple approache to keep the data in sync, isn�t it? The story could become little bit more complex though, because the container might have special features (that could be turned on and off) to allow caching the data between transactions. If that�s the case, the container will reduce the number of ejbLoad/ejbStore for improving performances.

Hi Mithal,
I hope you won�t mind if I�ll make some comments on your remark; this might help Hui to understand the complexity of this issue.

Entity bean is a good choice when you need to update a few rows in the db often, but not a good choice for query/search. You should be using JDBC for Reading. However, in your case with a million users, it makes no sense to retrieve their list. Entity beans are not suitable for OLAP data retrieval and you shud use the db vendor specific tool for this.

It�s true that inside the J2EE community there is a very strong feeling that entity ejb are a very cumbersome solution, which is a too complex issue to discus it here. There is also the other side of the barrier that says: it might be possible to build a good J2EE system using entity ejb. However this requires a very in-depth knowledge of the container and one will mostly end up implementing vendor specific solutions, which will break the J2EE essential promise "build once run everywhere". Only applying general J2EE knowledge might not be enough. To make long story short, I implemented once a solution like this, using read only entity beans for caching the data in order to provide fast access to a mission critical application; it worked just fine. I cached about several hundred thousand entity ejbs, which represented account structures and they were very large (more than 100 attributes each) data structures. The container behaved great and didn�t even seem to bother about the data it needed to cache. I guess the ultimate choice is whether to play safely, using JDBC for reading or to accept the challenge and assuming the risk of going with vendor specific ejb solutions.
Regards.