POJO Mojo

Distributed Shared Object (DSO) is meant to cluster virtual machines as one. It can greatly simplify challenges around scalability. It also places an emphasis on pure Java syntax and semantics.

bla bla blah

Terracotta is all about Java--clustering and caching Java apps as late in the cycle as post-deployment or as early as during design. We enable developers to write to one VM, scale to many. And we provide a simple development model--writing for one VM as if you were building a prototype--for distributed computing yet we inject powerful RAS characteristics at runtime. For Terracotta, clustering is more than just clustered caching.

We share data and coordinate that sharing. With just the JDK, nothing new to learn, no new code to edit, and no APIs to navigate. You could say we've got serious POJO MOJO. And, I am really excited about where we plan to take this technology. Terracotta has a vision for what I call the ultimate in runtime control--a topic for another time. How did we come across this view? This approach?

This article is the first in a three-part series of articles which examines how Terracotta DSO preserves object identity and how it is a key differentiator as compared to traditional API-based cache services.

• Part 1 explains what object identity is and why preserving it in a distributed cache is important.
• Part 2 examines how domain modeling suffers when object identity is not preserved.
• Part 3 illustrates how DSO preserves identity in a sample application.

We are pleased to announce the release of version 1.1.02 of Terracotta Virtualization Server. This maintenance release for the 1.1 line includes a number of important bug fixes.

Updated October 2006 for Terracotta 2.1

DSO is the transparent “Distributed Shared Objects” component of the Terracotta Server. It is an API-free way to convert a multi-threaded application to a multi-VM application, as well as a drop in session clustering tool for WebLogic. If this is your first time working with the DSO product, I recommend downloading the product from http://www.terracotta.org and working through the "Hello World Tutorial" and trying out the sample applications.

A common problem I run into when writing Distributed Applications is coordinating actions. Recently, while using DSO to write a Distributed Performance Test, I encountered this very issue. I wanted to start N nodes, have them wait until all N reach the point of load creation, and then simultaneously send load to the server.

The problem of managing conversational state (i.e. HttpSession) within a clustered web application is fairly well known. A clustered application that relies on the use of session data must have a robust and efficient session layer underneath it. The standard approach is to provide some form of data replication to another node(s) or to a database (gasp). All of the major application server vendors (and a few 3rd party products) provide mechanisms to enable data replication, BUT developers need to keep a fair number of constraints in mind when designing with these solutions (in no particular order):

• If the state of any object referenced by a session is modified, a call to setAttribute() is required to inform the system that replication is necessary
• Objects placed into session must implement java.io.Serializable and thus inherit the standard issues associated with serialization (performance overhead, versioning, duplicate instances upon de-serialization, etc)
• Session data may not be globally available within the cluster (depending on the replication model)
• Replicating data to other nodes has a significant impact on performance and memory usage
• Session replication is usually only available in higher priced “enterprise” or “cluster” editions of certain products