my dog learned polymorphism*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Another spec question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Another spec question" Watch "Another spec question" New topic
Author

Another spec question

Keith Rosenfield
Ranch Hand

Joined: Nov 25, 2003
Posts: 277
Hi all:
In section 10.5.3 of the spec, it says

public void ejbLoad();
When the container needs to synchronize the state of an enterprise bean instance with the
entity object�s state in the database, the container calls the ejbLoad() method. Depending
on its caching strategy, the container may first read the entity object�s state from the database,
before invoking the ejbLoad() method, or it may use a lazy loading strategy in making this
state visible to the instance.
The exact times that the container invokes ejbLoad depend on the configuration of the component
and the container, and are not defined by the EJB architecture. Typically, the container
will call ejbLoad before the first business method within a transaction.

Two questions:
1) Is ejbLoad() called before or after the container synchronizes the state of the enterprise bean?
2) What is meant by "lazy loading"?
Thanks,


Keith Rosenfield<br />SCJP<br />SCWCD<br />SCBCD
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Howdy -- the Container calls ejbLoad() as *part* of the synchronization process -- to get the bean state to match the state of the *real* entity in the underlying persistent store.
Lazy loading means that the Container doesn't have to load in the entire state of the bean. For example, if the Container can *tell* that the bean needs only the *address* to be loaded, then the Container might populate only the bean's address field, and leave the others in a stale state. But the Container always KNOWS when the bean *needs* a specific part of the bean's state, because the bean code will call one of the abstract getters. When the bean invokes an abstract getter, then the Container knows for certain that you need THAT piece of data (i.e. that particular column) but not necessarily any other data from the database, so the Container is free to synchronize on a field-by-field (i.e. column by column) basis when it does an ejbLoad(), rather than doing the entire load.
But this is up to the Container implementation. All YOU know for certain is that if you need access to the bean's state, through calling one of your CMP getters, the Container is responsible for making sure that at least THAT data is indeed synchronized (in other words *current*) with what is in the database.
cheers,
kathy
Keith Rosenfield
Ranch Hand

Joined: Nov 25, 2003
Posts: 277
Hi Kathy:
You cleared up my first question but I am still unclear on the second.
When you say
the Container is free to synchronize on a field-by-field (i.e. column by column) basis when it does an ejbLoad(), rather than doing the entire load.

what do you mean by "WHEN it does an ejbLoad()"? The way this is phrased it sounds like the container synchronizes the state and executes ejbLoad() simultaneously. Aren't these two operations distinct? Doesn't the container perform one operation then the next? Isn't the purpose of ejbLoad() to give the bean provider an opportunity to update any dependent fields after it has completed synchronizing the state?
Thanks,
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Another spec question