原文地址：http://www.wozaishuo.com.cn/article.asp?id=367
在<many-to-on>中這錯誤很常見，字面意義就是不能被初始化，因爲session已經關閉了。
簡單理解就是因爲，你使用了lazy=true，這樣hibernate在從數據庫中調數據的時候是不會把關聯的對象查出來的，而是保存一個獲取值得方法，在你使用getXXX()調用的時候，hiberante會利用這個保存的方法去從數據庫中取數據。而往往我們在jsp頁面中使用getXXX()準備展示數據的時候，session早已經在dao中就關閉了，我們該如何解決這種異常呢？
簡單的說有三種：
1.把lazy設成false,最2的辦法，但是最簡單，簡單就是美嘛，也依然會有很多再使用這個方式再解決類似問題。
2.我沒試過，但聽說過，應該可行.
在web.xml中加入
<filter-name>hibernateFilter</filter-name>
<filter-class>
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
</filter-class>
</filter
<filter-mapping>
<filter-name>hibernateFilter</filter-name>
<url-pattern>*.do</url-pattern>
</filter-mapping>
3.我用的方法，也是我認爲比較不錯的方法，靈活性更好。用left join fetch或inner join fetch語法。
例如：from Item i left join fetch i.parentItem ii
解釋一下Item表是一個自關聯的表，它的關聯關係在hbm.xml中配置好了。
如下：
<column name="PARENT_ID"></column>
</many-to-one>
在Item類中
利用left join fetch可以完美的解決這個問題。
希望能幫你解決困難，那樣我就知足了。
下面轉一篇不錯的文章，也是講could not initialize proxy - no Session問題的!
Could not initialize proxy - the owning Session was closed！
很多地方都已經著名解決方案了，爲了說明問題再重寫一遍！
但就此說一下關於lazy機制：
延遲初始化錯誤是運用Hibernate開發項目時最常見的錯誤。如果對一個類或者集合配置了延遲檢索策略，那麼必須當代理類實例或代理集合處於持久化狀態（即處於Session範圍內）時，才能初始化它。如果在遊離狀態時才初始化它，就會產生延遲初始化錯誤。
下面把Customer.hbm.xml文件的<class>元素的lazy屬性設爲true，表示使用延遲檢索策略：
<class name="mypack.Customer" table="CUSTOMERS" lazy="true">
當執行Session的load()方法時，Hibernate不會立即執行查詢CUSTOMERS表的select語句，僅僅返回Customer類的代理類的實例，這個代理類具由以下特徵：
（1）由Hibernate在運行時動態生成，它擴展了Customer類，因此它繼承了Customer類的所有屬性和方法，但它的實現對於應用程序是透明的。
（2）當Hibernate創建Customer代理類實例時，僅僅初始化了它的OID屬性，其他屬性都爲null，因此這個代理類實例佔用的內存很少。
（3）當應用程序第一次訪問Customer代理類實例時（例如調用customer.getXXX()或customer.setXXX()方法）， Hibernate會初始化代理類實例，在初始化過程中執行select語句，真正從數據庫中加載Customer對象的所有數據。但有個例外，那就是當應用程序訪問Customer代理類實例的getId()方法時，Hibernate不會初始化代理類實例，因爲在創建代理類實例時OID就存在了，不必到數據庫中去查詢。
提示：Hibernate採用CGLIB工具來生成持久化類的代理類。CGLIB是一個功能強大的Java字節碼生成工具，它能夠在程序運行時動態生成擴展 Java類或者實現Java接口的代理類。關於CGLIB的更多知識，請參考：http://cglib.sourceforge.net/。
以下代碼先通過Session的load()方法加載Customer對象，然後訪問它的name屬性：
tx = session.beginTransaction();
Customer customer=(Customer)session.load(Customer.class,new Long(1));
customer.getName();
tx.commit();
在運行session.load()方法時Hibernate不執行任何select語句，僅僅返回Customer類的代理類的實例，它的OID爲1，這是由load()方法的第二個參數指定的。當應用程序調用customer.getName()方法時，Hibernate會初始化Customer代理類實例，從數據庫中加載Customer對象的數據，執行以下select語句：
select * from CUSTOMERS where ID=1;
select * from orDERS where CUSTOMER_ID=1;
當<class>元素的lazy屬性爲true，會影響Session的load()方法的各種運行時行爲，下面舉例說明。
1．如果加載的Customer對象在數據庫中不存在，Session的load()方法不會拋出異常，只有當運行customer.getName()方法時纔會拋出以下異常：
ERROR LazyInitializer:63 -Exception initializing proxy
net.sf.hibernate.ObjectNotFoundException: No row with thegiven identifier exists: 1, of class:
mypack.Customer
2．如果在整個Session範圍內，應用程序沒有訪問過Customer對象，那麼Customer代理類的實例一直不會被初始化，Hibernate不會執行任何select語句。以下代碼試圖在關閉Session後訪問Customer遊離對象：
tx = session.beginTransaction();
Customer customer=(Customer)session.load(Customer.class,new Long(1));
tx.commit();
session.close();
customer.getName();
由於引用變量customer引用的Customer代理類的實例在Session範圍內始終沒有被初始化，因此在執行customer.getName()方法時，Hibernate會拋出以下異常：
ERROR LazyInitializer:63 -Exception initializing proxy
net.sf.hibernate.HibernateException: Couldnotinitializeproxy-theowningSessionwasclosed
由此可見，Customer代理類的實例只有在當前Session範圍內才能被初始化。
3．net.sf.hibernate.Hibernate類的initialize()靜態方法用於在Session範圍內顯式初始化代理類實例，isInitialized()方法用於判斷代理類實例是否已經被初始化。例如：
tx = session.beginTransaction();
Customer customer=(Customer)session.load(Customer.class,new Long(1));
if(!Hibernate.isInitialized(customer))
Hibernate.initialize(customer);
tx.commit();
session.close();
customer.getName();
以上代碼在Session範圍內通過Hibernate類的initialize()方法顯式初始化了Customer代理類實例，因此當Session關閉後，可以正常訪問Customer遊離對象。
4．當應用程序訪問代理類實例的getId()方法時，不會觸發Hibernate初始化代理類實例的行爲，例如：
tx = session.beginTransaction();
Customer customer=(Customer)session.load(Customer.class,new Long(1));
customer.getId();
tx.commit();
session.close();
customer.getName();
當應用程序訪問customer.getId()方法時，該方法直接返回Customer代理類實例的OID值，無需查詢數據庫。由於引用變量 customer始終引用的是沒有被初始化的Customer代理類實例，因此當Session關閉後再執行customer.getName()方法， Hibernate會拋出以下異常：
ERROR LazyInitializer:63 -Exception initializing proxy
net.sf.hibernate.HibernateException: Couldnotinitializeproxy-theowningSessionwasclosed
解決方法：
由於hibernate採用了lazy=true,這樣當你用hibernate查詢時,返回實際爲利用cglib增強的代理類,但其並沒有實際填充;當你在前端,利用它來取值(getXXX)時,這時Hibernate纔會到數據庫執行查詢,並填充對象,但此時如果和這個代理類相關的session已關閉掉,就會產生種錯誤.
在做一對多時，有時會出現"could not initialize proxy - clothe owning Session was sed,這個好像是hibernate的緩存問題.問題解決:需要在<many-to-one>裏設置lazy="false". 但有可能會引發另一個異常叫
failed to lazily initialize a collection of role: XXXXXXXX, no session or session was closed
此異常解決方案請察看本人博客（http://hi.baidu.com/kekemao1）的Hibernate異常中的《failed to lazily initialize a collection of role異常》
?
解決方法:在web.xml中加入
<filter>
<filter-name>hibernateFilter</filter-name>
<filter-class>
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
</filter-class>
</filter
<filter-mapping>
<filter-name>hibernateFilter</filter-name>
<url-pattern>*.do</url-pattern>
</filter-mapping>
就可以了;
參考了:
Hibernate與延遲加載：
Hibernate對象關係映射提供延遲的與非延遲的對象初始化。非延遲加載在讀取一個對象的時候會將與這個對象所有相關的其他對象一起讀取出來。這有時會導致成百的（如果不是成千的話）select語句在讀取對象的時候執行。這個問題有時出現在使用雙向關係的時候，經常會導致整個數據庫都在初始化的階段被讀出來了。當然，你可以不厭其煩地檢查每一個對象與其他對象的關係，並把那些最昂貴的刪除，但是到最後，我們可能會因此失去了本想在ORM工具中獲得的便利。
一個明顯的解決方法是使用Hibernate提供的延遲加載機制。這種初始化策略只在一個對象調用它的一對多或多對多關係時纔將關係對象讀取出來。這個過程對開發者來說是透明的，而且只進行了很少的數據庫操作請求，因此會得到比較明顯的性能提升。這項技術的一個缺陷是延遲加載技術要求一個Hibernate會話要在對象使用的時候一直開着。這會成爲通過使用DAO模式將持久層抽象出來時的一個主要問題。爲了將持久化機制完全地抽象出來，所有的數據庫邏輯，包括打開或關閉會話，都不能在應用層出現。最常見的是，一些實現了簡單接口的DAO實現類將數據庫邏輯完全封裝起來了。一種快速但是笨拙的解決方法是放棄DAO模式，將數據庫連接邏輯加到應用層中來。這可能對一些小的應用程序有效，但是在大的系統中，這是一個嚴重的設計缺陷，妨礙了系統的可擴展性。
在Web層進行延遲加載
幸運的是，Spring框架爲Hibernate延遲加載與DAO模式的整合提供了一種方便的解決方法。對那些不熟悉Spring與Hibernate集成使用的人，我不會在這裏討論過多的細節，但是我建議你去了解Hibernate與Spring集成的數據訪問。以一個Web應用爲例，Spring提供了OpenSessionInViewFilter和OpenSessionInViewInterceptor。我們可以隨意選擇一個類來實現相同的功能。兩種方法唯一的不同就在於interceptor在Spring容器中運行並被配置在web應用的上下文中，而Filter在Spring之前運行並被配置在web.xml中。不管用哪個，他們都在請求將當前會話與當前（數據庫）線程綁定時打開Hibernate會話。一旦已綁定到線程，這個打開了的Hibernate會話可以在DAO實現類中透明地使用。這個會話會爲延遲加載數據庫中值對象的視圖保持打開狀態。一旦這個邏輯視圖完成了，Hibernate會話會在Filter的doFilter方法或者Interceptor的postHandle方法中被關閉。下面是每個組件的配置示例：
Interceptor的配置:
<beans>
<bean id="urlMapping"
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="interceptors">
<list>
<ref bean="openSessionInViewInterceptor"/>
</list>
</property>
<property name="mappings">
</bean>
<bean name="openSessionInViewInterceptor"
class="org.springframework.orm.hibernate.support.OpenSessionInViewInterceptor">
<property name="sessionFactory"><ref bean="sessionFactory"/></property>
</bean>
</beans>
Filter的配置
<web-app>
<filter>
<filter-name>hibernateFilter</filter-name>
<filter-class>
org.springframework.orm.hibernate.support.OpenSessionInViewFilter
</filter-class>
</filter>
<filter-mapping>
<filter-name>hibernateFilter</filter-name>
<url-pattern>*. spring </url-pattern>
</filter-mapping>
</web-app>
實現Hibernate的Dao接口來使用打開的會話是很容易的。事實上，如果你已經使用了Spring框架來實現你的Hibernate Dao,很可能你不需要改變任何東西。方便的HibernateTemplate公用組件使訪問數據庫變成小菜一碟，而DAO接口只有通過這個組件纔可以訪問到數據庫。下面是一個示例的DAO：
public class HibernateProductDAO extends HibernateDaoSupport implements ProductDAO {
public Product getProduct(Integer productId) {
return (Product)getHibernateTemplate().load(Product.class, productId);
}
public Integer saveProduct(Product product) {
return (Integer) getHibernateTemplate().save(product);
}
public void updateProduct(Product product) {
getHibernateTemplate().update(product);
}
}
在業務邏輯層中使用延遲加載
即使在視圖外面，Spring框架也通過使用AOP 攔截器 HibernateInterceptor來使得延遲加載變得很容易實現。這個Hibernate 攔截器透明地將調用配置在Spring應用程序上下文中的業務對象中方法的請求攔截下來，在調用方法之前打開一個Hibernate會話，然後在方法執行完之後將會話關閉。讓我們來看一個簡單的例子，假設我們有一個接口BussinessObject：
public interface BusinessObject {
public void doSomethingThatInvolvesDaos();
}
類BusinessObjectImpl實現了BusinessObject接口:
public class BusinessObjectImpl implements BusinessObject {
public void doSomethingThatInvolvesDaos() {
// lots of logic that calls
// DAO classes Which access
// data objects lazily
}
}
通過在Spring應用程序上下文中的一些配置，我們可以讓將調用BusinessObject的方法攔截下來，再令它的方法支持延遲加載。看看下面的一個程序片段：
<beans>
<bean id="hibernateInterceptor" class="org.springframework.orm.hibernate.HibernateInterceptor">
<property name="sessionFactory">
<ref bean="sessionFactory"/>
</property>
</bean>
<bean id="businessObjectTarget" class="com.acompany.BusinessObjectImpl">
<property name="someDAO"><ref bean="someDAO"/></property>
</bean>
<bean id="businessObject" class="org.springframework.aop.framework.ProxyFactoryBean">
<property name="target"><ref bean="businessObjectTarget"/></property>
<property name="proxyInterfaces">
<value>com.acompany.BusinessObject</value>
</property>
<property name="interceptorNames">
<list>
<value>hibernateInterceptor</value>
</list>
</property>
</bean>
</beans>
當businessObject被調用的時候，HibernateInterceptor打開一個Hibernate會話，並將調用請求傳遞給BusinessObjectImpl對象。當BusinessObjectImpl執行完成後，HibernateInterceptor透明地關閉了會話。應用層的代碼不用瞭解任何持久層邏輯，還是實現了延遲加載。
在單元測試中測試延遲加載
最後，我們需要用J-Unit來測試我們的延遲加載程序。我們可以輕易地通過重寫TestCase類中的setUp和tearDown方法來實現這個要求。我比較喜歡用這個方便的抽象類作爲我所有測試類的基類。
public abstract class MyLazyTestCase extends TestCase {
private SessionFactory sessionFactory;
private Session session;
public void setUp() throws Exception {
super.setUp();
SessionFactory sessionFactory = (SessionFactory) getBean("sessionFactory");
session = SessionFactoryUtils.getSession(sessionFactory, true);
Session s = sessionFactory.openSession();
TransactionSynchronizationManager.bindResource(sessionFactory, new SessionHolder(s));
}
protected Object getBean(String beanName) {
//Code to get objects from Spring application context
}
public void tearDown() throws Exception {
super.tearDown();
SessionHolder holder = (SessionHolder) TransactionSynchronizationManager.getResource(sessionFactory);
Session s = holder.getSession();
s.flush();
TransactionSynchronizationManager.unbindResource(sessionFactory);
SessionFactoryUtils.closeSessionIfNecessary(s, sessionFactory);
}
}
我們首先說利用lazy=false來解決問題，這種方法是很好用，但是在實際的過程並不實用，如果你某個對象關聯好幾個甚至十幾個自對象，那麼每次加載一個的話要執行很多HQL語句，可想而知這個效率問題啦，特別是在使用列表的時候。所以不實用，而在上述所說的“在業務邏輯層中使用延遲加載” 也是這種情況吧。
很多使用WEB的朋友都喜歡利用openSessionView來加載這個問題。不錯我也喜歡用，簡單方便。但是說幾種情況：
1.在quartz中總不能使用openSessionView模式吧
2.在spring後攔截的過程中，如果取攔截對象中的子對象利用openSessionView也不行
還有很多情況是不能用的，那麼怎麼解決呢。有人說那就lazy=False吧，你想在單純的解決一個quartz的時候調整整個WEB工程的加載好像不合適吧。
那怎麼辦呢，我覺得這個時候就可以考慮利用SQL語句使用這個重新加載一遍這個代理類，這樣在想調用的時候才手動加載比較合適和方便吧，但是估計要多幾行代碼，好好考慮