newbie question..

[zena sam]

I have a question regd entity bean , as the concept is not clear to me...
Since the Entity bean represent the data in a table and each instance of the entity bean represents a row in a table.If there are 1000 records in a table ...will there be 1000 different instances of the entity bean??
Please clarify.
Thanks in advance!

[Ashish Pagare]

Yes however it depends on how many entity bean you create/access.
At the same time also remember that when ejbPassivate is invoked the entity bean will no longer be active inside your app server and I believe it will not hold a active connection with the database record. I guess as per spec ejbStore is called before ejbPassivate so the data will be persisted in DB when ejbPassivate is invoked.
I remember Kathy posted a long description on how the ejbRemove method differs for entity bean from SSBean. Just do a search.
HTH.

[Vishwa Kumba]

The entity beans are pooled, swapped in(activation) and swapped out(passivated) based on the usage patterns. Sometimes the database could contain a few hundred thousands or a few millions of rows. The number of entity beans available in the pool of the EJB container at any time would be much less than the rows in the database.

[Dave Cronin]

This question is not as straightforward as it may seem. Entity beans are meant to represent data that is both read and updated - they seem best for applications using them one entity at a time. If you had 1000 active references to entity beans it could cause performance problems - there might be 1000 simultaneous update transactions.
For the case of 1000 records, it is more likely you want only read-only access, in which case it may be best to access the data using SQL to return data as a table or some kind of collection. But even this may not work well with remote clients. There is a design pattern which address this problem, which allows small subsets of data collections to be returned to the client - Sun call it Value List Handler and there is a page about this at http://java.sun.com/blueprints/patterns/ValueListHandler.html

[Kathy Sierra]

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

[zena sam]

Thank you very much Guys,the answers are great...it really helps to understand the concept in depth...thanks a lot!!