Preventing lazy init when we know we want everything

View: New views
3 Messages — Rating Filter:   Alert me  

Preventing lazy init when we know we want everything

by mrtom852 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

I'm finding the use of lazy initialization to be intrusive to our application (we serialize objects a lot) and so I am trying to find a process where I can guarantee that an object _doesn't_ have any un-initialized members.

We have done some testing using FetchType.EAGER for collections but our provider (Hibernate) doesn't seem to respect this when there are many collections; it always wants to do fetch joins. I may have mis-understood what EAGER means so any clarification or suggestions on what other providers do would be welcome.

At the moment we have a hack that 'walks' all objects while the session is still open and I would like to avoid having to maintain this.

Regards,
Tom

Re: Preventing lazy init when we know we want everything

by James Sutherland :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Eager in JPA just means the relationship should be loaded, not that it should be join fetched, that is just an optimization that some JPA providers choose to do.  Given that you may want things EAGER so it is load, but in many cases do not want it join fetched, it doesn't sound like a good idea, especially for collection relationships where join fetches are not normally desirable.

Join fetches in JPA are only defined at the query level in JPQL, where they are normally best done.

TopLink Essentials the JPA 1.0 reference implementation does not join fetch when EAGER, also EclipseLink the JPA 2.0 reference implementation also does not join fetch when EAGER.  EclipseLink provides a separate mapping (@FetchJoin) and query option to enable join fetching if desired, so it can be configured separately to EAGER.

Re: Preventing lazy init when we know we want everything

by mrtom852 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

Thanks for your reply. It makes sense and is what I had expected. To be honest, the whole of our session management code is a mess (resume-driven-design) and I'll need to start over.

It's a shame that the session/EM doesn't provide some way to override policies on loading. Unless we use open-session-in-view it seems that JPA (or maybe it's just Hibernate) is very unpredictable unless we create lots of hacks.

In a proper EJB environment, where are the session boundaries? Does it provde a sort of open-session-in-view around the remote interfaces? Even though we won't use EJB, there is a lot that I'm sure we could learn from it.

Thanks again!

Tom