The right answer, to be obvious, depends on what the problem is.
You are dealing with a large number of clients and trying to keep track of objects - presumably belonging to the clients.
If these clients are anonymous (like people browsing a news site), your best bet would be to keep the objects as attributes of a stateful session bean.
If your clients are known and keep coming back for more sessions, you then have the choice that you are thinking about - entity beans or direct JDBC calls from session beans/JSP pages to the database.
JDBC calls are simple and well understood, but have limitations on functionality and performance.
The pressures to move to entity beans are :-
1. If the same object is used by multiple users, accessing an entity bean means that the object is only read from the database once.
2. If operations are performed on the object - say, order total = sum of order lines - it's far more efficient to do this on an object in memory than to go back to the database.
3. If you have complex objects, it may be difficult and expensive to transform the objects from database to entity beans and vice versa.
I don't know of any useful advice on this subject with metrics attached. The people who earn megabucks by answering these questions are not going to give us their knowledge for free.
I suggest that you hide your access to objects behind an interface, giving you the opportunity to explore different approaches to persistence later.
I attach an example of an interface that allows access from an entity bean and from a JDBC connection to a database.