I'll mainly be speaking in general EJB terms, rather than
JBoss-specific, since JBoss takes the attitude that the EJB
Specification "is more what you'd call 'guidelines' than actual rules.
Welcome aboard the Black Pearl, Miss Turner."

When you (as the client) call a finder method, the EJB container first
calls the bean's ejbFindByXXX method to get the Enumeration of primary
keys (PKs) to be found. Then for each of those keys it looks for an
existing EJBObject, and if it doesn't find one it creates one; from
this it builds the Enumeration of EJBObjects that the finder method
returns to you. Note that since these are Enumerations, what you get
is not necessarily a true list of EJBObjects; the EJBObject does not
*need* to be created until you ask for it via nextElement(). The
container can handle this as it pleases.

In the ordinary case, when you first call a method on each of those
EJBObjects, the container will first call the ejbLoad method of the
object which will then execute an SQL SELECT ... WHERE PK = mypk. This
results in N+1 SELECT statements being executed when accessing N
entity beans (the +1 being the one executed by the finder).

For CMP Entity Beans, some containers provide an "eager loading"
option where you can specify that the container should immediately
preload some number of the EJBObjects when the finder is executed. For
JBoss, I believe that this is called "read-ahead". The obvious
advantage is that the container can preload a number of EJBObjects
with a single SELECT statement, rather than loading them one at a time
as they are needed. The disadvantages are related to loading so many
table rows at one time: container memory usage, concurrency problems
from tying up all of the rows within a transaction, lock escalation if
applicable, increased latency before the first EJBObject is
accessible, and possibly wasted effort if you only needed to access a
few of the rows.

In general, the number of EJBObjects to be preloaded has to be
limited. The container cannot rationally commit to building and
populating an EJBObject for every row returned from any given query;
there could be millions (or billions) of rows in the response.

The fundamental problem is that you are using Entity Beans when you
are concerned with performance.

JBoss attempts to reduce some of the performance issues with Entity
Beans, occasionally by ignoring the EJB Specification. If you're
planning to commit to using JBoss (in other words, portability is not
an issue), you will need to become familiar with making the most of
the various JBoss CMP performance extensions. As a start, a quickie
Google turned up http://linuxintegrators.com/jbossBlog/bburke/?permalink=Optimizing+JBoss%3A+Expe
riences+with+SPECj2002.html
which I cannot personally vouch for as I am not a JBoss user. If you
want portability to other containers, you should seriously consider
getting rid of the Entity Beans wherever performance is an issue.