通过将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上。一般采用后者。
另外，已经可以买国内的凯发k8网页登录的技术支持服务了。唯一遗憾要到12月份的tc2.7版，才会支持glassfish 2。