Question

I’m running into LazyLoading exceptions like the most people who try remoting with an ORM.
In most cases switching to eager fetching solves the problem (Lazy Loading / Non atomic queries / Thread safety / n+1 problem …). But eager fetching has also disadvantages if you are dealing with a really big object graph.

Loading the whole object graph isn’t needed in the most use-cases. It feels bad to load more data then needed (or load them from the db and extract the needed subset).

So what alternative ways are there to solve this kind of problem (at runtime)?
I’ve seen:

• Inject a data access dependency into domain object and let the object decide either to load lazy or eager: Feels bad! The domain layer should be independent from any service. Domain injection is also an expensive operation. The domain should be data access ignorant and should be used with or without data access.
• Fetch everything lazy except of use-cases which require more data: Seems better for performance but this way forces many client=>server / database roundtrips. The initialisation of the lazy fields can also suffer pain (tried with JPA). This way doesn’t feel generic and is subject of the same lazy restrictions mentioned above.
• Encapsulate persistence in Lazy class: More complexity, no best practice for interoperation with ORM. Bloating services layer (so much “hand written” code feels bad).
• Use full projections for every use-case: We’ll end up in SQL and drop the benefit of an ORM.
• A DTO / Virtual Proxy layer enforces more complexity and makes code harder to maintain (Wormhole antipattern >> Bloat).

I thought a lot about another way. Maybe generic projection white./black listning is a solution.

Idea (blacklist): Define an classname list with the boundaries for a fetching operation. If a property matches and it’s lazy, remove the lazy (CGLIB) proxy and fill the value with null. Else, simple prevent from fetching (and leave value at null). So we can set clear boundaries in our DAOs.

Example: ProductDao.findByName("Soap",Boundaries.BLACKLIST,"Category, Discount")
the two last parameters can also been bound into a Boundaries object.

Idea (whitelist): Like blacklist, but you must declare properties with should be loaded in a whitelist.

What do you think about such a solution? (Possible problems, restrictions, advantages …)
How should I write this in java? Maybe via AOP to match DAO methods (because I’m able to modifiy cglib proxy behaviour there)?

Answer 1

1. You can get rid of all collections whatsoever and use NamedQueries instead. We used this approach in one project (EJB + Swing), and it worked pretty well – thus you determine exact data to be fetched.
   NamedQueries are normal queries, imagine them as PreparedStatement-s. The idea is not to create/retreive/update/delete single objects with queries. The idea is that you fetch your Collections with queries. For example, instead of mapping a @ManyToMany List, define a NamedQuery that fetches that list. Thus you can fetch the collection data separately, and only whenever you need it, not automatically.

2. Use a custom Proxy (using CGLIB) for transferred objects – whenever a collection is referenced (via its getter), attempt retreival, and catch any LazyInitializationException and make a call to the server tier for the data requested.

3. Just as the previous one, but make proxies only of the collections, in the way Hibernate proxies them when lazy initialization is needed.

4. Also, take a look at the Value List Handler pattern – might be useful.

(You can also use hibernate.max_fetch_depth (if using Hibernate) with a combination of the above, if it is suitable for your case.)