Scaling Applications across Multiple JVMs

Clusters and grids remain the inevitable choice when you have to battle out
issues of scalability, high availability, high performance or even fail-over. It
is not that this has not been adopted for Java applications, the clustering or
grid is more of API based. Thus, you can cluster application servers but not the
objects or more importantly the state of these objects when you plan to expand
your application over a cluster or grid. In this series, we look into a
clustering solution called Terracotta that does clustering at the JVM level. The
Terracotta solutions allow clustering without changing the existing code of your
application. It uses a declarative pattern using which you can configure your
application for JVM level clustering. This part looks into Terracotta DSO
(Distributed Shared Objects), the core technology for clustering JVMs and the
basics concepts related to the clustering.

Terracotta basics

We talked about clustering of application servers a while ago and weren't all
praises for it. Let us examine why. We used a commercially available Application
Server and created a cluster on 10 workstations, each running its own JVM for
deploying a Web app to test how efficient this clustering is in comparison to
using an application in a single application server on a server machine. We
could configure what modules of the sample application will be installed on
either a part of this cluster or throughout the cluster, or even choose a few
nodes for installing the application and assign fail-over nodes. So far so good,
but there lie a few differences in this clustering and the one Terracotta
provides. For one, you have multiple application servers

running as one unit, but is there any in-built mechanism provided for state
management or concurrency? By in-built, we mean whether these things can be
managed without topping up your application with additional APIs. That is, it
doesn't necessarily ensure that an object's state in (say) the heap of a node is
known globally. If needed, it has to be taken care of by developers. Two, it is
certainly not a cluster of the objects in our application. For overheads, you
would certainly know the dreaded 'S' (Serialization) that comes into play in
Java EE clustering.

This is where Terracotta is different. Clustering at JVM level means that all
the JVMs act as a single unit. But this eases out a lot of burden, as once there
is one single JVM acting globally, any changes in the heap of a particular JVM
are replicated throughout the network. In case network overheads are the next
issue on your mind, that's not a bottleneck because a change in any field of a
globally shared object would require replication of that field only. We will
show this a little later in the series that Terracotta does exactly that. So,
instead of a cluster of application servers with there own heaps invisible to
each other, we have a cluster of JVMs which gives a global virtual heap A lock
becomes a cluster-wide lock; a shared object's update becomes a cluster-wide
update. Most importantly, you don't have to explicitly make such things visible
throughout the cluster.

Distributed Shared Objects

Distributed Shared Objects (DSO) is the core technology enabling clustering
services at the JVM level. The best part is that you don't need to import any
DSO libraries for clustering your application. DSO works at the byte-code level.
When you declaratively configure your application for clustering, relevant
changes are applied at the JVM, which Terracotta terms as hooks. These hooks,
then, keep track of field updates in the instantiated objects that have been
declared as 'Shared Roots'. The changes are then informed to the Terracotta
Server that further replicates these changes across VMs. Configuring the
application requires declaring which objects are to be shared, or replicated
across VMs, which classes to instrument, ie those classes whose instances are
being declared shared roots, or have distributed locks or distributed methods.

While doing all this, you just have to create appropriate configuration files
for enabling your application for DSO. So, the entire exercise's critical phase
is to realize what has to be declared as shared and distributed and where locks
are to be applied and which kind of locks are to be applied.

Clustering with Terracotta

Let us look into the procedure for enabling an application for Terracotta. As we
had said earlier, you do not need to import any libraries into your code for
this. You rather need to work on generating the 'Terracotta-Config' file, which
describes the clustering for your application. First, you have to determine
which objects are to be shared. It largely depends on the characteristics of
your application. But a generalized view that can work to start with, is to look
for objects in your application that represent state information and form the
core of your applications' logic. Be careful not to include objects that appear
to be shared objects, but if scrutinized further are actually objects with a
particular JVM, for eg sockets, connections, etc). You, then, mark fields in
these objects to be replicated across the cluster. Terracotta follows a distinct
approach when it comes to initialization of the shared objects. The shared roots
are initialized only within the cluster and the very first 'not-null' reference
that is initialized is assigned to the cluster. Any subsequent assignment of
reference is ignored. Terracotta implements this semantic to prevent the
application code from changing it in context to the cluster.

This is a reason why we said earlier that you have to exercise what has to be
shared rather than getting into tearing apart your existing modules or adding
code to existing application code. While shared objects are integral to
clustering, so are locks as you need to maintain integrity of data members
throughout the cluster. These locks are termed 'Distributed Locks' in Terracotta
lingo. They help keeping data members' values synchronized cluster wide. Locks
can also be 'Named' so that methods of similar names use the same lock. These
are of help in methods written without any thread safety considerations.

In conclusion

So far, we have underlined the basic concepts regarding Terracotta DSO and
clustering. In the upcoming parts of the series, we will look into basic
examples such as how to go about configuring an application for DSO, and later
on how to enable your Spring Objects for Terracotta. In fact, the product
documentation lists a few simple examples such as Slider Application, which can
be referred to get a good idea of how to use the Terracotta Eclipse Plugin and
how to configure an application for 'Terracotting' it.