Dear All,
          I have query whether the retrieval of data from entity bean's findBy... method is efficient, in terms of network resources used and time taken, or accessing data directly through database is efficient.

Thank You,
Sameer.

hi Sameer,
u can access the database directly from the seesion bean,no doubt but the problem would be that u will be coupling ur system very tightly to the underlying architecture.
I will defenitely prefer to use Entity beans.

But yes if the query is trivia i will access(only read) using session beans
hope this helps
KT

If the number of rows expected is large, I would go for a session bean.

Regards
RK

Using entity beans is usually better design. Basically it depends on how many of the resultant beans you want to use. For example, if you just want to do a count it would be likely to be much more expensive to use an entity finder than to use a session bean.
Most app server vendors agree that doing JDBC in session beans is more efficient. However, you won't get the object abstraction of entities, or the transactional behaviour offered "out of the box" by entities.
Some app servers may offer "lazy loading" for entities, that might minimize the overhead of retrieving entities you don't end up using.
Caching (for example in a session bean) can also be used to minimize lookups, but retain the advantages of entities.

Mr. Rod Johnson:

If i have large amount of records to be returnd
to web client, do you have sugestions for me?

1. caching in server or client better?
2. like search engines behavor
3. does weblogic have this cache limits?
4. Will it effect server performance?

1. Pros and cons with each. If you cache on the server, your cache is automatically threadsafe, can be used by multiple clients, and you may be able to take advantage of your app server's functionality. If you cache on the client, on the other hand, you can minimize remote calls by caching Serializable "details" objects rather than remote objects. If it's read only data and your "client" is a server-side web app, I'd cache on the client. Under these circumstances, this will be MUCH faster.
2. Do you mean a paging concept? I guess you'd have to implement this using a custom finder. Something like findByRange(...). The issue here would be to ensure that your finder always returned the paged data in the same order. You could handle this in SQL, assuming you're using a relational database. It would perform well.
3. Not sure about how WebLogic cache limits work. Anyone know?
4. I wouldn't worry too much about how many objects you have on the server, more on the number of remote references you have and the number of remote calls you need to make. Both of these will be a performance and scalability issue.

Regards, Rod

Instead of enterprise beans (both session and entity) won't it be better if there are some kind of helper classes which can be used to obtain data directly from database. Because such retrieval of data is presenttion need, not business logic, and as enterprise beans are reusable components, writing such methods in enterprise beans will tightly couple beans with a particular application.