Distributed Spring - Spring Enterprise Recipes: A Problem Solution Approach - page 389

com.apress.springenterpriserecipes.distributedspring.

➥
terracotta.customerconsole.view.CustomerServiceImpl.customers</field-name>
</root>
</roots>
</dso>
</application>
</tc:tc-config>
The servers element tells Terracotta about how to the server behaves: on what port it listens, where
logs are, and so forth. The application instance is what's of concern to us. Here, we first spell out which
classes are to be clusterable in the instrumented-classes element.
The locks element lets us prescribe what behavior to ensure with regard to concurrent access of
fields on classes. The last element, the field-name element, is the most interesting. This instruction tells
Terrracotta to ensure that the changes to the customers field in the CustomerServiceImpl class are visible
cluster-wide. An element inserted into the collection on one host is visible on other hosts, and this is the
crux of our functionality.

10-2. Using Spring to Simplify Terracotta Configuration

Problem
You want to simplify configuration and have Terracotta cluster entire beans in Spring. Ideally, you'd like
to let Terracotta resolve the information that we're already defining about classes in Spring.

Solution
Terracotta supports specialized configuration just for Spring. You can reference beans by bean name
and it'll take care of resolving associated members of the object graph.

Approach
The configuration that we saw in the last recipe works fine for most cases, but it can quickly become
tedious. Let's turn to Spring to simplify things, conceptually. In the previous example, we built an
unnervingly simple application and then complicated it by introducing an XML configuration file. This
situation would be further frustrating if we were using Spring, in which case we'd have to configure the
same entity and service, two different ways.
Terracotta can benefit your Spring application directly and indirectly. In this example, we discuss
using Terracotta to scale out Spring configured beans, directly. However, Terracotta also offers a
powerful Ehcache integration and (in newer versions) there is Terracotta-based Hibernate provider as
well. Thus, if you're using Ehcache with Hibernate, or as a separate install, this is a compelling option.
Further, if you're using Hibernate and choose to use the Terracotta-based caching provider, there's
value in Terracotta. Another area where Terracotta may significantly speed up your application is with
its support for the HTTP Session. This can generally be useful to any web application, but in particular it
can be very powerful for Spring Web Flow, which manages HTTP session memory.
Terracotta supports configuration using Spring-specific elements that let it infer a lot of the same
data that we configured explicitly in the last example. First, let's take a look at the configuration of the
classes as Spring beans. There's no need to put these collaborators together using Java; we merely need
to acquire our reference from the context ( customerconsole-context.xml ).