Performance and caching

[lempinen]

Greetings!

I am using MySQL as the backend for CMP beans, and I am running into performance problems.

I have a particular bean class that maps to a database table with approx. 5000 rows. I need to repeatedly retrieve *all* objects of this class. With the default caching settings, iterating through the objects returned by findAll() takes about three minutes. I have tried tuning the cache as per the manual, and got the response time to increase to about 40s. But this is still too slow.

What are my options from here on? Is there something wrong with the configuration? Is there a convenient way of pooling the objects without resorting to application-side cache?

Thanks in advance for any input.

-Sami

[markd]

Are you interacting with each EJB retrieved on the client?

If so, each method call is a remote call and this will contribute to the delay. Look at the ValueObject design pattern for a method to reduce network communication. Once you have implemented the ValueObject pattern, you can also create a Session Facade to create the ValueObjects or to create an applcation-side cache with the ValueObjects.

We had a process that retrieved a large number of Entity Beans that ran slow as well. Closer examination of the problem was traced down to the fact that the finder causes one SQL statement to be executed to load the references and then the first access to each entity bean causes another SQL statement to be execute to load the entity bean. So to access 5000 rows, 5001 SQl statements where executed to load them into cache. Once loaded into cache, they ran very fast, except in our case the collection was only accessed once a day. Therefore, we wrote JDBC code in the Session Facade that retrieved all the data with one SQL statement and created the ValueObjects from the result set. This totally bypassed the caching, but we were not using it anyway.

Another way to avoid the SQL statement is to store the collection retrieved by the findAll() in an "owning" EntityBean and tune your cache to be sure that it is not passivated. The assumption is that calling a finder that creates a collection of 5000 Entity Bean references is expensive.

All this is based on JBoss 2.4.3 and ejb 1.1. I have not yet been able to get JBoss 3.0.0 to work yet and ejb 2.0 may do much of this for you.

[jhicks]

What are you doing with the beans? If you are only wanting to read the data, use a slsb with a DAO to access the database directly. This is alot faster. You could even use the ValueListIterator pattern to iterate over the data.

Really, I can't see any reason why you would want to update every single bean at once.