What is the best practice for using lazy loading in a DAO?

I currently have a DAO which opens/closes a new session for each operation.
This works fine, but for performance reasons, we've now had to enable lazy loading for some collections.

To avoid LazyInitizationException, I've been experimenting with a modified OpenSessionInView pattern:

At the start of a request. a session is opened, and its flush mode set to FLUSH_NEVER.
This session is solely used for reads (call it 'reader'). Objects returned are flagged as read-only.

To save an object:
. the 'reader' session is cleared
. a 'writer' session is established
. the object is saved using 'writer' in a transaction
. the 'writer' session is closed.

The reader session is cleared so that:
. the object and any children aren't being managed by 2 sessions
. to force the 'reader' session to reload any modified objects subsequent to a save.

This approach seems to work, and retains the behaviour of the existing DAO but isn't very elegant. Is there a better approach?

-Tim

http://hibernate.org/42.html
http://hibernate.org/43.html

Thanks - I'd found both of those pages. I was looking for something more specific.
The DAO currently detaches objects from the session. I need to retain this behaviour (in the logical sense), to ensure that changes to objects are only persisted through calls to the DAO.

have BaseHibernateDao with a method returning SessionFactory.getCurrentSession() and all your DAOs inherit it to acess the session. So you have 1 session/thread or request instead session/each operation.

Unfortunately a single session only works for the simple case.
Clearing the read session before each write causes LazyInitializationExceptions afterwards in more complex object graphs. Touching the objects to avoid this is not really an option.

It appears I need to:
1. use an OpenSessionInView pattern for reads, opening a new session for each read. Session closure is deferred to the end of the request.
2. create a new session for each write

However, the latter requires that I evict the object being written from the session that read it, or I get:
"Illegal attempt to associate a collection with two open sessions"

Is it possible to get the session that currently manages an object, or do I need to maintain a map of objects to sessions, in order to do the evict()?

In the end, I did away with OpenSessionInView. It doesn't seem to be a workable solution where a DAO is used and the objects must be detached from the session (or at least appear to be).

The workaround was to add an API that provides support for partial object queries. This touches the requested object properties to avoid LazyInitializationException, prior to closing the session.