2009年8月27日
#
可以把Spring配置成Listener，它在Filter啟動之前就已經加載。
eclipse異常退出，在Navigator視圖看不到項目了，重新導一次項目就可以了。
重新編譯沒有用，說是找不到一個jar里的某個類，把這個類從編譯路徑刪除，再加入，代碼會重新編譯，之后發現沒有錯誤提示了。
2009年8月6日
#
異常機制的本質是，當程序出現錯誤時，幫助程序員鎖定錯誤，并對程序進行修正。
現代程序的規模已經大到讓人無法全知的程度，因此
異常機制是一種很有效的機制。
找出錯誤體系，逐層細化，
并最終構成一個異常體系。
和JDBC savepoint，回滾等結合起來，就要看JDBC代碼了，走太遠不好，夠用就行。
2009年8月5日
#
要辨別事務的邊界。就是啟動事務和提交事務的邊界。 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的優秀功能之一。
事務的隔離級別是由底層數據庫實現的。而事務的傳播行為這是應用程序自己管理的。
2009年8月1日
#
前不久，國內某著名企業的架構師給我們做的講座中提到了對象的序列化技術。
可見序列化，是一個必須全面了解的概念。
剛才看Python編程，發現Python也有序列化機制，就是把除了基本類型外的對象進行存儲，中間的一個過程是把對象轉換成一定格式的二進制流。
還有其他多種序列化技術? 如使用JSON也是一種序列化機制?
10.16
剛才使用了簡單的串行化方法。
在memcached中，應該要用到串行化方法吧?