Bean in Entity bean pool lost identity?

[G.I. joe chen]

I just don't understand.
After entity bean is called ejbPassive(), then it goes to Entity bean pool.
Did it the bean lost the primary key?
If lost, how come when ejbAcitvate() called, getPrimaryKey() can be called?

[Nathaniel Stoddard]

Welcome to JavaRanch "hello joe joe". You should change your name to your actual name before one of the moderators pops in with the "official notice"!
To answer your question though, when a bean is in the pooled state it isn't assigned to any actual entity beans. It's just sitting there waiting for something to do. When the EJB container wants the bean to get back to work, it loads all of its fields, including the primary key, so it can do its work. So, it hasn't "lost" its primary key at all. It's just taking a break.

[G.I. joe chen]

Thanks for remind me about the display name.
for the problem, so you meant the bean did not lost identity,
it just wait for other call. If any one call, it will ejbLoad() again.
Got it.
Another question. We know that a entity bean = a record in a table, but for a particular record, how many entity bean for that record exist in bean pool? one is OK, will there be two entity bean in pool which represents the same record?

[Nathaniel Stoddard]

When beans are in the pool, they are not associated with any entity bean. They have no data associated with them. If you have 1 entity bean in your database, there may be a million beans in the pool. But none of them are associated with the one entity bean in your database. When a client calls a method the EJB container will take a bean from the pool, fill its values and then handle the call.
Just remember that when beans are in the pool, they're just sitting there. They aren't associated with any data or records in the database. It's just like baseball players on the bench. When they're on the bench they're just sitting there. But when the coach tells them to go play on the field, he may put them in as pitcher or right field or whatever he needs.
Maybe that's a bad analogy, but does it make more sense now?

[G.I. joe chen]

Thank you very much Nathaniel!

1. you said "They have no data associated with them" for bean in pool.
did the bean carry a PK?
2. if you replied no, then when container call ejbActivate() of this bean, why it can call a getPrimaryKey() method?

[Nathaniel Stoddard]

1) Is a primary key data? Yes. A bean in the pool is not associated with an entity. A primary key is only associated with an entity bean. Therefore a bean has no primary key associated with it while it is in the pool.
2) I said that the EJB container loads all the data before the bean goes back to work. The ejbActivate() method really means "Hey bean--you have all your data now--get back to work." So at that point, it can get its primary key.

[G.I. joe chen]

how about ejbLoad()? after ejbActivate(), the container will call ejbLoad() to actually load data, right?

[Nathaniel Stoddard]

Sorry, let me make a few corrections. Geez.
ejbActivate just says that the bean has been activated and is associated with an entity bean. But the only data that it really has is the primary key, which is why you can retrieve it while in ejbActivate. After that ejbLoad is called. If the bean is a BMP bean, ejbLoad will be by the actual bean to load the persisted values from somewhere. If the bean is a CMP bean, ejbLoad is just used as an event notification that all the values are initialized to their correct values.
Bean lifecycle issues are by far the hardest part of the exam. So, make sure you have a copy of the specification handy. I'm on page 185 of the 2.1 version. It even has a nice diagram. In addition, I'd check out the API documentation for a brief description of what each callback method actually means.

[G.I. joe chen]

Million thanks to Nathaniel!
Does it meant
1. after ejbPassvite(), all data cleared (for the bean) except PK;
2. Entity bean in pool carry a PK but no other data;
3. when ejbActivate(), bean come out;
4. when ejbLoad(), other data comes.
I also checked the spec. (After read HFB, still a little confuse in this point, therefore look up the spec. by myself). But still not very clear.
Thanks

[Nathaniel Stoddard]

Okay, let's start from the beginning:
The container starts, creates a few bean instances and puts them in the pool for later use. Those beans are in the "pooled state." The container calls setEntityContext() on each so they know about it.
After that, when the container needs one of the beans, it sets the bean's primary key to associate it with an actual entity bean that is stored in the database somewhere. Then the container calls ejbActivate() to let the bean know that it's being activated. The only data the bean has access to at that point is the primary key. The bean is now in the "ready state."
After that, the container calls ejbLoad to allow BMP beans to retrieve the rest of their data, or to notify CMP beans that the rest of the data values are stored in the bean. At this point, the client calls a bunch of methods and all the cool stuff EJB does.
At some point the client will be done with the bean. It may not be used for a while and the container wants to save some memory. At that time, the container will invoke ejbStore() to let a BMP bean store its data to a database or somewhere else, or to notify a CMP bean that its values have been stored in the database.
After that, the container will call ejbPassivate() to let the bean know that it is being passivated. At this point, it again only has access to the primary key. After ejbPassivate finishes, the bean is back in the "pooled state" to remain there motionless and useless until the container needs it again and the bean finds itself back in ejbActivate.
This is just a high-level view, mind you. There are other things that can happen in the lifecycle. For example, if there's a runtime exception, ejbPassive and ejbStore won't even get called. The container will just kill the instance.

[G.I. joe chen]

Thank very much. Understand now.

[Nathaniel Stoddard]

Great! Now, go change your name ... again.

[Niki Sharma]

>>Just remember that when beans are in the pool, they're just sitting there. They aren't associated with any data or records in the database. It's just like baseball players on the bench. When they're on the bench they're just sitting there. But when the coach tells them to go play on the field, he may put them in as pitcher or right field or whatever he needs.
Why baseball.. why not basketball.. good discussion

[Nathaniel Stoddard]

Well, being the avid sports nut that I am, I can't actually name a single basketball position. Do basketball players have positions? Hmmm.

[Roger Chung-Wee]

Does it meant
1. after ejbPassvite(), all data cleared (for the bean) except PK;
2. Entity bean in pool carry a PK but no other data;

Every bean in a pool has no identity, so the Container can assign any instance to any entity object within the same entity bean home. So how can the bean obtain the PK upon activation? The answer, I think, lies in the fact that every bean instance has an entity context, and it is the responsibility of the Container to ensure that this context is always associated with the instance.
So, before or during activation, what I think happens is that the Container associates the entity context with the bean by invoking the bean's setEntityContext() method. This is why, in ejbActivate(), the PK can be obtained directly from the context's getPrimaryKey() method (or indirectly from the bean's EJB Object). The reference to the EJB Object is obtained from the context's getEJBObject() method.