馬可波羅的夢鄉(xiāng)

可以把Spring配置成Listener，它在Filter啟動之前就已經(jīng)加載。

eclipse異常退出，在Navigator視圖看不到項目了，重新導一次項目就可以了。
重新編譯沒有用，說是找不到一個jar里的某個類，把這個類從編譯路徑刪除，再加入，代碼會重新編譯，之后發(fā)現(xiàn)沒有錯誤提示了。

異常機制的本質(zhì)是，當程序出現(xiàn)錯誤時，幫助程序員鎖定錯誤，并對程序進行修正。
現(xiàn)代程序的規(guī)模已經(jīng)大到讓人無法全知的程度，因此異常機制是一種很有效的機制。

找出錯誤體系，逐層細化，并最終構(gòu)成一個異常體系。

和JDBC savepoint，回滾等結(jié)合起來，就要看JDBC代碼了，走太遠不好，夠用就行。

要辨別事務的邊界。就是啟動事務和提交事務的邊界。 DAO對象的每個方法都對應于一些數(shù)據(jù)庫操作。如果需要把兩個或更多個方法作為一個事務，則需要在更高的層次定義事務。

Spring的一個好處是為事務提供了一個統(tǒng)一的抽象，不論底層是用什么實現(xiàn)，如Hibernate, IBatis或者JDBC，都可以使用一個統(tǒng)一的接口。
如果用Spring來管理Hibernate事務，最好不要直接使用Hibernate事務接口，因為這會造成混亂。如果使用Spring來管理Hibernate事務，那么就調(diào)用Spring的接口。

事務中獲取的Connection必須是和事務關(guān)聯(lián)的那個Connection，不能直接調(diào)用DataSource的getConnection，如果得到的是不同的Connection，是無法實現(xiàn)事務的。因此，最好調(diào)用Spring的事務工具類。

事務管理器，事務狀態(tài)，事務發(fā)起，事務提交，事務回滾等。
Spring事務，對系統(tǒng)性能的影響有多大，那些更復雜的分布式事務如何處理，如何衡量它的性能損耗呢?

JTS是底層接口，JTA是高層接口。
JDBC事務是局部事務，只能應用于當前數(shù)據(jù)庫。如果事務跨多個數(shù)據(jù)庫，就必須使用分布式事務。這個時候可以采用JTA。
JTA事務，涉及一個事務管理器和多個資源管理器。資源管理器可以是任何持久性數(shù)據(jù)存儲系統(tǒng)，包括數(shù)據(jù)庫系統(tǒng)、MIS系統(tǒng)、JMS等。

JDBC驅(qū)動只有實現(xiàn)了XAConnection和XAResource接口才能參與JTA事務。但是一些高級JavaEE服務器可以將普通JDBC驅(qū)動模擬為支持XA的JDBC驅(qū)動，這個模擬過程是如何完成的?

XAConnection和JDBC Connection的事務操作是不同的，它絕不能自動提交，也絕不能調(diào)用XAConnection的commit和rollback方法，只能調(diào)用UserTransaction對象的begin，rollback和commit方法。 如何看其底層實現(xiàn)機制。或者沒有必要。

如果只有單個數(shù)據(jù)庫，使用JTA會帶來不必要的復雜性。不過對于Spring來說，使用哪種事務已經(jīng)不重要了，因為它定義了一個統(tǒng)一的抽象事務編程模型。并配合聲明式事務，選擇JDBC事務，還是JTA事務，所需要做的，僅僅是修改配置文件。 一般不會涉及代碼的修改，這是Spring的優(yōu)秀功能之一。

事務的隔離級別是由底層數(shù)據(jù)庫實現(xiàn)的。而事務的傳播行為這是應用程序自己管理的。

前不久，國內(nèi)某著名企業(yè)的架構(gòu)師給我們做的講座中提到了對象的序列化技術(shù)。
可見序列化，是一個必須全面了解的概念。
剛才看Python編程，發(fā)現(xiàn)Python也有序列化機制，就是把除了基本類型外的對象進行存儲，中間的一個過程是把對象轉(zhuǎn)換成一定格式的二進制流。
還有其他多種序列化技術(shù)? 如使用JSON也是一種序列化機制?

10.16
剛才使用了簡單的串行化方法。
在memcached中，應該要用到串行化方法吧?