Terracotta, the last piece of puzzle for pojo Development Model

By sharing pojo objects in a cluster, the terracotta container makes pojo no longer limited to the SNA (share nothing impact ect) architecture, and supports the cluster mode transparently, this is the last piece of puzzle for pojo development models.

In fact, it is a central cache server. After adding the terracotta parameter to the application startup command, classloader modifies bytecode In the JVM-level way according to the configuration file. You can transparently store the object on the central server.

For performance, it uses Object Attributes rather than the entire object as the storage unit; for availability, it also supports the master and slave clusters.

Colleagues from the Research Institute and the project team have been using it on their site for a long time. They have also followed suit these days.

I like this kind of "pre-commercial projects" and generally have good tools.

• Sessions configurator. Run the tc-confg.xml in debug mode under a pre-configured dual-machine cluster, let you observe the value of the shared object changes, when the runtime error occurs, prompt configuration file missing error correction.
• Eclipse plug-in. Set the tc-config.xml by right-clicking any class, attribute, Function Point.

It is said that the user is transparent, but it is only the best wish, and some code may be modified:

• Synchronization problems. The original standalone program is changed to a cluster for running. If you cannot run the program, you must first change the code of the shared object class to thread-safe, such as using the thread-safe concurrenthashmap and atomicinteger attributes, or add synchronized control to the access attribute code. Then configure the terracotta autolock in XML to extend the lock to the cluster range and set the batch update attribute transactions with the lock as the boundary.
  The reverse understanding of TC's CTO's speech on tuning has a significant impact on performance if the locks are poor.

• Local Resource attributes. Some local attributes such as file handles cannot be shared. In this case, you need to configure the transients attribute. This property is forced to be null in another JVM. What should we do? The recommended practice is to write another init function that initializes these attributes and configure the call in the tc-config.xml. The less intrusive approach is to write the beanshell script directly in the tc-config.xml, but this script is not easy to write.

At last, TC undertakes the function of implementing the pojo cluster, but the TC server itself has the risk of spof and needs to be configured with the cluster mode. In the persistent HA cluster mode of TC, all data will be persist to the disk. The cluster will always have only one active node, and other nodes will act as passive nodee. Active Node failover and client reconnection are transparent. Passive and active node allow you to use the same disk space that supports file locks, or allow the active node to synchronize all changes to the passive node through the network. The latter is generally used.

In addition, you can buy technical support services in China. The only regret is that the tc2.7 version will support glassfish 2 by December.