memory usage with EntityBeans

For example, I have a groups of EntityBeans. Each EntityBean matches one row in my database table. If my table is huge, say, it has millions of records. We don't want to load all the records into millions of EntityBeans. How to we deal with this problem.
Thanks in advance ...

It is way too much if you are creating a entity bean for each row in your databases. And it will be a bottle neck.
I presume u meant to say, each table is mapped to a Entity Bean and each row for sure goes with its own primary key. This is the basic first timer approach to Entity Beans. This will also be a bottleneck performance wise when it comes to database to the scale you are talking.
This is exactly why we need to look at the broader picture of the system as a whole(compared to the database driven view) and create some entity beans that represent couple of tables together. This is called 'Composite Entity' approach. This needs more understanding of normalization in some cases and some smarts inside your composite entity. This approach will sure save tons of performance for systems that look into large database tables(sizewise).
For more details on composite Entity you may refer to 'J2EE design patterns' by Deepak Alur etc.
Dan

Actually I didn't mean that much.
If a user does a query which will return thousands of records, and there are thousands of such users doing similar queries concurrently ...
What's going to happen? Assume entity beans are used ...

Originally posted by Edy Yu:
If a user does a query which will return thousands of records, and there are thousands of such users doing similar queries concurrently ...
What's going to happen? Assume entity beans are used ...

Let's just say that you don't want to do that with entity bean finders. Instead, you can use JDBC to pull back just the summary information you need as well as implement paging if necessary. This is not possible using entity bean finder queries.
If you insist on using the finders, you can at least create business methods that perform the query and select a subset of the results for pulling back summary data. With WebLogic at least you have control over whether or not the beans are fully loaded as a result of the query. You would turn this *off* so that only the PKs are retrieved.
As you build out your service you could add query caching and paging. Note that this continues to be a thorny problem for most people. For our user search we use JDBC (dynamic, one-to-four-field query) and limit the results to some configured maximum (100). It's not as nice as paging, but if you cannot narrow your user search down to 100 people, you probably won't find them anyway.