Terracotta Shared Memory Pool

[was TransparentlyClusteringJavaObjects]

---

What if you could write thread-safe Java objects for a single server, and have the JVM transparently virtualize them, for distributed operation across a cluster of logical and physical machines?

The Terracotta Virtualization Server (TVS) offers an interesting option: Instrument the code so that (for selected distributed classes), native Java operations, such as synchronized coordinate their actions across a cluster of JVMs. Object identity, state and locks can transparently be distributed across JVMs.

"DSO, or Distributed Shared Objects, is our API-free, clustering component of the Terracotta Virtualization Server, that allows several Java Virtual Machines (JVMs) to appear and act as one JVM. DSO eliminates the need to maintain state in a transactional database."

• Distributed Shared Objects (DSO)
• Terracotta Virtualization Server

URLs:

• http://terracotta.org/
• http://www.terracottatech.com/

(While JSR-107, the "JCACHE - Java Temporary Caching API" (http://www.jcp.org/en/jsr/detail?id=107) provides a way to "distribute" objects across a cluster, it has its limitations and difficulties: It's not at all transparent to the application, for instance.)

Jonas Bonér gave a quite informative presentation titled "Transparently Clustered Spring" at the SpringExperienceConference?: http://jonasboner.com/?p=78

ITConversations should publish the audio recording from the presentation (eventually).

---

This sounds like it is quite well fulfilled by Sun's new Darkstar project -- the SunGameServer?. While the project is meant to be for MMORPG's, it presents a single-threaded environment while putting all the state in the program (Game Logic Objects) into a DB and atomicizing access to them. It can distribute across multiple JVMs and computers.

---

How does this work? If I had to do it, I would try to duplicate the ideas of MozartOs?/OzLanguage. I would write a classloader, that instruments all loaded java classes by replacing access to instance variables in the way Oz does it and migrate objects to the server where they are accessed. This would be transparent, but require some smarts to handle inherently local native Java classes (like File or Runtime). The drawback of this approach would be, that it would have a performance penalty for every instance variable access.

They instrument classes at load time by customizing the system ClassLoader. They also modify and replace a number of Java classes, such as the 'java.lang.util' Collections classes, to make them distribute(d)/(able).