this link is a good start. the stuff about interceptors may not be relevant to your case right now, but I think you'll find some useful information here.
http://www.hibernate.org/43.html
quoted from that page.
Why can't Hibernate just load objects on demand?
Every month someone has the idea that Hibernate could instead of throwing a LazyInitializationException just open up a new connection to the database (effectively starting a new Session) and load the collection or initialize the proxy that has been touched on-demand. Of course, this idea, while brilliant at first, has several shortcomings that only appear if you start to think about the consequences of ad-hoc transactional access.
If Hibernate would, hidden from the developer and outside of any transaction demarcation, start random database connections and transactions, why have transaction demarcation at all? What happens when Hibernate opens a new database connection to load a collection, but the owning entity has been deleted meanwhile? (Note that this problem does not appear with the two-transaction strategy as described above - the single Session provides repeatable reads for entities.) Why even have a service layer when every object can be retrieved by simply navigating to it? How much memory should be consumed by this and which objects should be evicted first? All of this leads to no solution, because Hibernate is a service for online transaction processing (and certain kinds of batch operations) and not a "streaming objects from some persistent data store in undefined units of work"-service. Also, in addition to the n+1 selects problem, do we really need an n+1 transaction and connection problem?
The solution for this issue is of course proper unit of work demarcation and design, supported by possibly an interception technique as shown in the pattern here, and/or the correct fetch technique so that all required information for a particular unit of work can be retrieved with minimum impact, best performance, and scalability.