通过将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.
