Hello,
I read from docs that "ejbLoad is called during synchronizing the database fields back" but it's
not clear why it's called when an ejbFind is performed.
I thought that it's necessary to synchronize the "status"
of DB when an update (insert,remove etc.) occours,
so why ejbLoad needs to be called also with Find?
Thanks
Francesco

I dont see any reason ejbLoad() would be called during a finder operation. What container?

Dave Wolf
Internet Applications Division
Sybase

It's issued using Weblogic 5.1. I can read from Weblogic docs "Weblogic calls ejbLoad to read the most current version of the bean's persistent data".
Is it different under other container?
Thanks
Francesco

As far as I understand, WLS5.1 calls ejbLoad() only when the first method on the Remote Reference of the bean is invoked. However, this behaviour can be overriden by setting <finder-call-ejbLoad> to true. This would enable the finders methods to invoke ejbLoad(), otherwise NOT.

How to set <finder-call-ejbLoad> to false for a Bean Managed Persistence?

vijay

You can't... That's a CMP only feature.

WebLogic complies with J2EE spec pretty well, so it should work as any other J2EE-compliant EJB container.

Here's what happens when a finder method is called:

1. The Bean's find code is executed
2. One or more Entity Bean primary Key class instance is returned
3. When the results of the finder method are returned to the client, the container loads the actual instance of the Bean into the memory and gives you a pointer to its Remote Interface (this is sometimes dependent on the container; for example, in IONA's container, you have to call ejbFindByPrimaryKey yourself in order to locate the actual Bean; WebLogic 5.1 works as described above)

Thus, ejbLoad gets called for every Bean instance that is found during a finder operation.

Leo

Hello!
it's interesting, I came up exactly at this point of discussion in another thread in Troubleshooting-ejb.
As a matter of fact I tried to build a large cache
of data, issuing ejbFind methods. After 100 records Weblogic complained that I overcome the limit of 100 beans in cache. And now you definitely confirm it, that ejbFind methods actually load instances into memory.
One further begging: how do I get rid of these beans loaded into memory?
Thanks for your patience!
regards
Francesco

Yes, please see 9.1.4 of the spec which states

1) ejbFind() occurs only in the method ready state
2) Finders occur before the method ready state, and hence there should be no ejbFind() in this state
3) After the finder completes the bean enters trhe method ready state
4) Now the container may call ejbLoad()/ejbStore() zero or more times.

In EAServer we skip the ejbLoad() as its repetitive, but BEA issues this call. Its legal, just IMHO wasteful.

Dave Wolf
Internet Applications Division
Sybase

Actually, WebLogic's behavior can be either / or, depending upon how you have the deployment descriptors configured. In WLS 6.0 with the new EJB 2.0 container, the ejbLoad() is not called until a TX is started and a remote invocation is made or you specify the <finder-call-ejbload> tag in the deployment descriptor.

In fact, WLS even takes this a step further in their new container: you can have lazy loading of fields and grouped field loading. First, lazy loading of fields will only load fields into memory if:

a) the object is in the Ready State
b) the field is referenced directly. The CMP container knows this because to be compliant with EJB 2.0, your bean class must have all of its persistent fields coded with accessors such as getField() and setField(). The container knows to pull a variable into memory whenever one of the bean methods calls getField(). The getField() calls super.getField() (which is a container implementation class) that can determine the persistent field to load by doing reflection).

Another benefit is "grouped fields". In this situation, if one of the fields in the group is accessed, then all of the other fields in the same group (specified in the deployment descriptor) will be loaded into memory concurrently as a single statement.

Tyler

Oh, and WebLogic was able to eliminate the need for the <is-modified-method-name> for CMP entity beans because the container intuitively knows whether or not the bean has been modified. In a setField() method has never been called since the last commit AND <db-is-shared> is false, there is no reason to perform a write!

Tyler

And, I most definitely concur with Dave in that any vendor that calls ejbLoad() right after the ejbFind(...) completes is very wasteful.