Entity Beans and performance

[frebe73]

Hello,

I am evalutating entity beans (BMP) performance and I have found following problems:

If you want to get all employees for a department you can have a EmployeeBean-class which have a findByDepartment-method. That method will make a select-SQL in the database fetching the primary keys for all employees in one department. Next, the EJB-container will call ejbLoad on EmployeeBean-class for each employee and ejbLoad will make a select-SQL. The resulting number of database calls is one for each employee plus one.

A traditional solution would have been to make a single select-SQL to get all employees. I made a test with both solutions and found the traditional solution to be tree times faster.

Have I misunderstood the entity beans model? I can't understand that a well-accepted model have that bad performance. Are you using entity beans out there? I would be thankful to have some comments to this problem.

A ugly solution to this problem would be to let the primary key class contains all data for the entity bean. For every findXXX-method all data should be loaded in the primary key object. The ejbLoad-method just copies data from the primary key object to the bean. Does anyone have any comments to this work-around?

/Fredrik Bertilsson

[hstech]

Fredrik,

For the scenario you are talking about, I would expect you to find an Entity Bean to be inefficient. You would be better off using a Session Bean that retrieves the list of employees with a single SQL statement and then iterates through the list, packaging the results as serializable data objects (check out the Sun Java design patterns/blue print site for best-practice suggestions).

The primary benefit of Entity Beans is rapid development. However, if you were instead dealing with the scenario of updating the address for a single employee, you may find the performance of the Entity Bean more acceptable.

I personally don't find Entity Beans provide enough benefits to warrant using them in my designs, but I'm sure other people out there find them useful for various reasons. Like anything in this game, you can use whatever you like, as long as you've thought about the implications and can justify your choice.

Cheers,
Aaron.

[wimflam]

If I understand the docs correctly, I believe that JBoss 2.4 contains an optimisation that may help you.
In the section relating to finders in the volunteer docs, the read-ahead tag is mentioned.
This tag seems to enable some optimisation which will preload the EJB's using only one query.
I haven't actually tried this approach, but I would be interested in hearing from anyone who has, and what results they had.

I have a similar problem myself, and it seems that working with finders that produce Collections has issues in JBoss ( or perhaps EJB in general ).
I have a scenario, where I have maybe 300 countries stored in a database table.
I want to present these countries in a localised drop down menu. This means that I need to access 300 entities (via a findAll), and then perform a further 300 lookups to get the countries name in a given language.

These 600 accesses take several seconds, and I need the process to take only milliseconds.
I don't know where the performance issue is, as theoretically, JBoss should only query the database the first time I access these beans. Perhaps there is a bottleneck in deferencing the beans, or perhaps (God forbid) the problems lies in my code! ;-)

My solution to this problem will be to cache the data from the beans in memory, as fortunately my application is suited for this.

[davidjencks]

Assuming your data is not going to change...

Make sure you have

Commit option A -- prevents reading from db on each "getxxx" call, so data is cached after first read.

readahead turned on -- should read all 300 rows in one query execution

read-only (I'm not 100% sure this is implemented in 2.4)turned on, or implement isModified or use tuned updates. -- prevents writing back to the db after every getxxx method call (the container can't tell without some help if your "getxxx" actually changes stuff, so it by default has to write back to the db after every such call).