Missing link in entity bean finder methods !

[Reghu Ram Thanumalayan]

Hello Friends,
According to the entity bean life cycle , After a finder method executes on the home object of an entity bean, the bean will still be in the pool. But to call a business method on the EJBObject returned by the finder method, the bean has to be in the method ready state. So for the transition to take place from the pool state to method ready state, ejbActivate has to be called by the container before executing the business method.
But with the AccountBean example given in the Book “Mastering EJB “ by Ed Roman, which I tried out on Weblogic Server 6.1, the ejbActivate method was not called when a create call had been previously executed before the finder method call and subsequently a business method on the EJBObject returned by the finder method.
The ejbActivate was called only when the calls were finder methods and a business method.
So how did the transition take place? Was the finder method executed in the method ready state? Does my previous statement make any sense? Please guys make me clear.Am i missing something here ?

[David Harrigan]

Hi,
From my understanding, when a container does an ejbCreate<METHOD> on a bean, the bean is already instantiated and in the pool. The container invokes the ejbCreate<METHOD> and the bean is in a method-ready state.
ejbActivate() is only called after ejbFind<METHOD> (although, this is not a requirment - page 255, paragraph 2).
Because the bean had previously been created, in your example, the ejbActivate method did not have to be executed.
The container choose to ejbActivate after your finder and business methods.
Hope this helps
-=david=-

[Philippe Maquet]

Hi Reghu,
The specs don't garantee that ejbActivate() and ejbLoad() will ever be called ! ejbActivate() is only called if the Container uses commit option C (and is never called when commit options are A or B).
I tried to explain that in my post dated December 30, 2003 07:49 PM in this thread, and as nobody contradicted me till now on that topic, I still believe that I was correct .
Regards,
Phil.
[ January 06, 2004: Message edited by: Philippe Maquet ]

[Reghu Ram Thanumalayan]

So the container is not required to invoke the ejbActivate method. So does that mean that finder methods can execute in the methods ready state ? In the life cycle diagram of entity beans, that link is missing. Only the ejbSelect, business methods, ejbLoad and ejbStore are shown to be executing in the method ready state ! Am i correct ? Make this clear guys !

[Philippe Maquet]

Hi Reghu,
Yes, you are correct. In comparison with ejbSelect*() methods (which are called by the Bean Provider from a business or home business method), ejbFind*() methods will only be called as a result of a client call to some home find*() method.
Regards,
Phil.

[Reghu Ram Thanumalayan]

Hi Phil,
So you mean to say that, since the ejbFind method is invoked in response to some HomeFinder method, the ejbFind method is shown to be executing in the pool state. But in the scenario which i presented, there should have been a call to the ejbActivate if the container strictly followed the life cycle diagram. But its upto the container to decide on this issue. if it can find out that the bean is already in method ready state ie associated with an EJBObject, then it may not invoke ejbActivate. I guess i make sense now... Thanks guys,

[Jats Tan]

I continuation of this discussion, concerning the Entity EJB lifecycle, I dont understand why ejbActivate is called on an instance when ejbFind has been called on an instance and it has returned a PK to the Appserver(Home object).At this stage,the instance fields are instantiated and the bean is in a method-ready state.
But it seems from the EJB lifecycle diagram, that even after ejbFind has been called, the bean is still in the pool with no state associated to it,which is incorrect.
Guys,What did i miss in the ejb spec??

[Kathy Sierra]

Howdy -- this is a good question, and one that gets a lot of people.
Jats, you really should think of an entity bean has having two separate jobs--ONE is to *be* an actual entity ("Now I am John Smith, PK # 72) and another job is to be a "finder/home business method service on behalf of ALL entities of my type". When a bean is performing that second job, it is acting almost like a stateless session bean, in that one entity of that type is the same as any other entity of that same type. So, a Customer entity bean in the pool, running a Finder method, is the same as any other entity bean.
The confusion is about what happens when the bean is asked to run a single-entity Finder, like findByPrimaryKey("24")
In this case, the bean does not ever BECOME entity #24, Bob Izarra. Instead, the bean just LOOKS to be certain that #24 is actually IN the database. That's all. The bean is never populated with Bob (#24) Izarra's data. The bean never BECOMES Bob Izarra. It simply runs the Finder, checks to see that yes, Bob is in the database, and returns the PK as confirmation. So after a Finder, the bean's instance variables are NOT set and the bean is NOT in a business-method-ready state. It's simply still sitting in the pool waiting to run a Finder/Home Business method OR to come out of the pool through ejbActivate() or ejbCreate().
So, the question is WHY doesn't the bean come out of the pool and become Bob Izarra? After all, that means TWO hits to the database... one to do a select to see if Bob, #24, is in the database, and then ANOTHER once the client wants to USE that bean to invoke a business method.
Yes, it seems a little less efficient if the client really DOES want to USE the bean once they've found it (and in fact, some servers *do* let you tune for this, but it is not part of the spec).
But... it is MORE efficient to do it this way overall, because once the client has obtained a *reference* to the bean (the purpose of a finder), then the next time the client calls a business method, that bean's data may have changed in the DB, and another SELECT will have to run anyway (which means another ejbLoad()). So, by keeping the bean in the pool, it saves the Container from having to load all of the bean's data and populate the bean's fields UNTIL the client actually *gets serious* and invokes a real business method. At that time, the Container says, "OH, I guess you need some real data loaded in the persistent fields, so it does a SELECT on whatever other data it needs to now use to populate the bean's fields.
There are other issues that make it a little more complex, but as far as the specification is concerned (and the exam) THIS is how it works. Always. Bean stays in the pool to run Finders or home business methods, so once a client *finds* a bean and thus gets a reference to the bean's EJBObject, the bean won't necessarily be loaded and populated until the client USES the reference to invoke a business method.
Hope that helps...
- Kathy

[Jats Tan]

Thanks Kathy.This is interesting...
So, basically what you are saying is that the bean instance which initially does the ejbFind could be a different one from the instance which is later loaded when the client invokes the business method. Correct?
Secondly, what about the BMP case?? In a BMP,as per your explanation:
"...Instead, the bean just LOOKS to be certain that #24 is actually IN the database. That's all. The bean is never populated with Bob (#24) Izarra's data...".
But, 'Mastering EJB' shows the "loading" of all the fields and initializing the data members in the ejbFind, and then returning the PK to the Container.Where is the bean instance after that...in the pool..?..in the cache...?