Lazy loading with bussines tier best practices

micho2001 · **Posted:** Tue Oct 14, 2003 1:27 pm

Hi all!

Hibernate docs on lazy loading.

Quote:

In an application with a seperate business tier, the business logic must "prepare" all collections that will be needed by the web tier before returning. Usually, the application calls Hibernate.initialize() for each collection that will be needed in the web tier (this call must occur before the session is closed) or retrieves the collection eagerly using a query with a FETCH clause

(IMHO) I think the manual could use a little more detail here.

Im using hibernate with the spring framework (so far so good), which makes it easier to handle DAO's for each entity and associate to each DAO a sessionFactory.

Each time I call a one of the DAO methods a hibernate session is opened and closed. This means that once I load an object (say myDAO.load(id) )
this object becomes .transient, simply because it's no longer associated to a session.

This implies that in a typical lazy collection scenario one would:

1. Load the parent object in one session (parent becomes transient) i.e:
//in Session 1
session.load(Parent.class, new Long(id));
2. Load the desired collection (this means associanting the parent to a session i.e:
// in Session 2
session.refresh(parent));
Hibernate.initialize(parent.getChildren());

So my doubts are: is there a way to associate a transient object to a session without going to the DB? Would other people recommend using Filters over this approach (in my particular case children collections are not that big).

I've had no problem so far getting lazy collections to work, but I would like to know how other people handle lazy collections in a bussines tier... Maybe I just got it all horribly wrong!! :-(

micho2001 · **Posted:** Tue Oct 14, 2003 1:40 pm

Another doubt:

I have DAO's that use different underlying persistence (i.e: JDBC, or Hibernate). How could you "hide" the fact that your using lazy loading? For example , how would the API a DAO for a Parent with two different lazy collections look like?

Best I cant think of right now is something like:

Code:

public class ParentDAO  implements IParentDAO{
private SessionFactory 

//example for  some CRUD operations. 
//Each method opens and closes a session


public Parent findById(long id){
...
}

public void delete (Parent p){
...
}

//Initialize collection 1
public void initializeBoys(Parent p){
...
}


//Initialize collection 2
public void initializeGirls(Parent p){
...
}


}

Suggestion, comments or just flame are welcome ;-)

jhoeller · **Posted:** Tue Oct 14, 2003 3:06 pm

What about giving findById flags like

Code:

public Parent findById(long id, boolean loadGirls, boolean loadBoys);

Of course, code calling the finder would have to know which subcollections are needed in the first place to make this work.

Juergen

emmanuel · **Posted:** Tue Oct 14, 2003 6:48 pm

Does Spring Framework allow you to open an hibernate session before your dao calls ?

Code:

myBusinessMethod() {
  session = Helper.openSession();
   obj1 = dao1.doStuffs();
   dao2.doStuff(obj1);
   obj1.getLazyCollection();
   session.close();
   //try catch are missing.

Every lazy loading issues are done. I think the ThreadLocal session pattern is used in Spring, so yes is probably the answer to my question.

jhoeller · **Posted:** Wed Oct 15, 2003 9:07 am

epbernard wrote:

Does Spring Framework allow you to open an hibernate session before your dao calls ?
(...)
Every lazy loading issues are done. I think the ThreadLocal session pattern is used in Spring, so yes is probably the answer to my question

Good point! Spring automatically binds a Session to the thread in a transaction, so you'd just need to execute both your DAO calls and the lazy collection initialization within a transaction (either programmatically or declaratively).

It's similar with Hibernate's (or JDO's) automatic change detection: You can modify objects returned by a DAO in a business method and expect automatic flushing of changes, as long as you execute within a transaction. If not using a transaction, the objects returned by a DAO are no longer associated with a Session, therefore changes are not flushed.

Juergen

aalishan12 · **Joined:** Fri May 24, 2013 6:30 am **Posts:** 1

It's similar with Hibernate's (or JDO's) automatic change detection: You can modify objects returned by a DAO in a business method and expect automatic flushing of changes, as long as you execute within a transaction. If not using a transaction, the objects returned by a DAO are no longer associated with a Session,