TerraCotta  通過將POJO對象在群集內下的共享，讓POJO不再局限于SNA(Share Nothing Architect)的架構，比較透明的支持了集群模式，可謂POJO開發模型的最后一塊拼圖。

　　其實它的原理很簡單，本身是一個中央式的Cache服務器。在應用啟動命令中添加Terracotta參數，Classloader就會根據配置文件在JVM級以AOP方式修改ByteCode，用戶透明地將對象存儲于中央服務器。

　　為了性能，它以對象屬性而不是整個對象為存儲單位；為了可用性，它本身也支持主備集群。

　　研究院和項目組的同事們早就在他們的地盤上用上了，這幾天自己也跟風了一把。

　　很喜歡這種"前商業項目"，一般都會有不錯的工具。

• Sessions Configurator 。以Debug模式將tc-confg.xml運行在一個預配置的雙機集群下，讓你觀察共享對象的數值變化，出現運行時錯誤時，提示配置文件缺漏錯誤的修正。
• Eclipse插件。通過對著任意的類、屬性、函數點右鍵來設定tc-config.xml。

　　說是用戶透明，其實只是最美好的愿望，可能還是有些代碼修改：

• 同步問題。原本單機運行的程序，改成集群運行，跑不掉的是先要將自己共享對象類的代碼改為線程安全的，如使用線程安全的ConcurrentHashMap 、AtomicInteger屬性，或在訪問屬性的代碼中加入synchronized控制。然后在xml中配置Terracotta的autolock將鎖其擴展到群集范圍，設定以鎖為邊界的批量更新屬性的事務。反向理解TC的CTO同志關于調優的講話，鎖沒搞好的話對性能影響挺大。
• 本地資源屬性。有些很local的屬性如文件句柄是沒辦法共享的，這時候就需要配置為Transients 屬性。這種屬性在另一個JVM里就會被強制設為Null。怎么辦呢？推薦的做法是另寫一個初始化這些屬性的init函數，在tc-config.xml中配置調用。更少侵入的做法是直接在tc-config.xml中寫beanshell腳本，不過這腳本不好寫。

　　最后TC承擔了實現POJO集群的功能，但TC Server本身就存在單點故障的危險，需要配成Cluster模式。在TC的Persistent HA Cluster模式中，所有數據會Persist到磁盤，Cluster中永遠只有一個Active Node，其他節點就作為Passive Nodee。Active Node的失效切換與Client的重連都是透明的。 Passive 與Active Node使可以用同一塊支持文件鎖的磁盤空間，也可以讓Active Node將所有變化通過網絡同步到Passive Node上。一般采用后者。