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上。一般采用后者。

       另外，已经可以买国内的技术支持服务了。唯一遗憾要到12月份的TC2.7版，才会支持Glassfish 2。