Howdy -- I don't have much to add, because everyone else gave great answers. The bottom line is that your app server will, by default, *not* "bring to life" each row in your database. When I say "bring to life", I mean populate an entity bean with that row's data. (And I'm using the
word "row" loosely, but that's the easiest way to think of it).
As others said, your app server will likely keep ONLY the entities that are currently being accessed by clients, plus some number of recently-used entities (if it uses the most popular commit option, that keeps an entity around, attached to an EJB object, for some time after it has completed a transaction.) Not all app servers will immediately passivate a bean following a transaction. Most servers try to be more efficient about it (all that passivation/activation is more overhead), so it is always a trade-off between the performance hit of multiple passivation/activation cycles, versus having more beans around than clients really need.
Remember the three commit options that the Container can use for "what to do with the entity bean after it finishes a transaction"
* Passivate the bean (following ejbStore(), of course). This releases any locks on the database.
* Keep the bean attached to the EJB object (following ejbStore(), but still RELEASE the locks on the database. This means the bean is *not* passivated immediately, and when a new transactional method is called on the bean, the bean still gets an ejbLoad(), but it does *not* have to go through ejbActivate(). This is perhaps the most common approach used by app servers. At some point, the Container will recognize that the bean is not being accessed, and will passivate it... or the Container may use a passivation scheme that depends on how many resources are being used relative to how much the Container has available (in other words, "if RAM is getting dangerously low... start passivating!" similar to what most Containers do for stateful session beans).
* Keep the bean attached to the EJB object AND keep the locks on the database. This would almost never be a default that an app server would use, since it would mean that you could get to the database ONLY through the bean, and not through any other application. But... this could potentially give you the best performance if you DO know that it's OK to keep the database locks, because the EJB app is the only thing that can get to the database anyway. Because it means that with each new transaction, the bean is already fully loaded, ready to go. No new ejbActivate() and ejbLoad() needed. Not all app servers can do this, even if you *want* them to, but it is one of the three options a vendor has, according to the specification.
I *have* heard of a few rare applications that do this deliberately, in order to have a lightning-fast in-memory database. For example, a genetic matching application that loads everything into beans -- the entire database -- can perform these matches far, far, faster than other mechanisms. Orders of magnitude improvements. But that is a special case.
Again, most of the time what you *want* and what the server *does* is to keep a bean attached to an EJB object for some period of time, using some good LRU (Least Recently Used) algorithms to determine when it's probably a good time to passivate a bean because nobody seems to care about it now...
cheers,
Kathy
