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.
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.
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).