可以把Spring配置成Listener，它在Filter啟動之前就已經加載。
eclipse異常退出，在Navigator視圖看不到項目了，重新導一次項目就可以了。
重新編譯沒有用，說是找不到一個jar里的某個類，把這個類從編譯路徑刪除，再加入，代碼會重新編譯，之后發現沒有錯誤提示了。
異常機制的本質是，當程序出現錯誤時，幫助程序員鎖定錯誤，并對程序進行修正。
現代程序的規模已經大到讓人無法全知的程度，因此
異常機制是一種很有效的機制。
找出錯誤體系，逐層細化，
并最終構成一個異常體系。
和JDBC savepoint，回滾等結合起來，就要看JDBC代碼了，走太遠不好，夠用就行。
要辨別事務的邊界。就是啟動事務和提交事務的邊界。 DAO對象的每個方法都對應于一些數據庫操作。如果需要把兩個或更多個方法作為一個事務，則需要在更高的層次定義事務。
Spring的一個好處是為事務提供了一個統一的抽象，不論底層是用什么實現，如Hibernate, IBatis或者JDBC，都可以使用一個統一的接口。
如果用Spring來管理Hibernate事務，最好不要直接使用Hibernate事務接口，因為這會造成混亂。如果使用Spring來管理Hibernate事務，那么就調用Spring的接口。
事務中獲取的Connection必須是和事務關聯的那個Connection，不能直接調用DataSource的getConnection，如果得到的是不同的Connection，是無法實現事務的。因此，最好調用Spring的事務工具類。
事務管理器，事務狀態，事務發起，事務提交，事務回滾等。
Spring事務，對系統性能的影響有多大，那些更復雜的分布式事務如何處理，如何衡量它的性能損耗呢?
JTS是底層接口，JTA是高層接口。
JDBC事務是局部事務，只能應用于當前數據庫。如果事務跨多個數據庫，就必須使用分布式事務。這個時候可以采用JTA。
JTA事務，涉及一個事務管理器和多個資源管理器。資源管理器可以是任何持久性數據存儲系統，包括數據庫系統、MIS系統、JMS等。
JDBC驅動只有實現了XAConnection和XAResource接口才能參與JTA事務。但是一些高級JavaEE服務器可以將普通JDBC驅動模擬為支持XA的JDBC驅動，這個模擬過程是如何完成的?
XAConnection和JDBC Connection的事務操作是不同的，它絕不能自動提交，也絕不能調用XAConnection的commit和rollback方法，只能調用UserTransaction對象的begin，rollback和commit方法。 如何看其底層實現機制。或者沒有必要。
如果只有單個數據庫，使用JTA會帶來不必要的復雜性。不過對于Spring來說，使用哪種事務已經不重要了，因為它定義了一個統一的抽象事務編程模型。并配合聲明式事務，選擇JDBC事務，還是JTA事務，所需要做的，僅僅是修改配置文件。 一般不會涉及代碼的修改，這是Spring的優秀功能之一。
事務的隔離級別是由底層數據庫實現的。而事務的傳播行為這是應用程序自己管理的。