Using the Terracotta Toolkit standalone vs inside a DSO application

Stand-Alone Terracotta Toolkit

It is possible to use the Terracotta Toolkit all by itself to very easily gain access to much of Terracotta’s power.  When used in a stand-alone fashion, you just need to get a Terracotta Server up and running in its simplest form.  Once you do that, clients are built using just a little bit of Java code.  You don’t need to mess with XML at all or understand instrumentation of code, locking definitions, shared roots, or any of that stuff.  It’s really easy.

To use the Toolkit in this fashion, you just need to do two things:

  1. Do an “express” install of Terracotta Server
  2. Link your client code against “terracotta-toolkit-1.0-runtime-1.0.0.jar”

You get a reference to the ClusteringToolkit interface via the following line of code:

ClusteringToolkit toolkit = new TerracottaClient(“terra-server:9510”).getToolkit();

That’s it!  It’s just that easy to cluster your Java apps!

Here are a series of very simple tutorials that might help you get started with standalone Toolkit use:

Getting Started: Part 1, Part2, Part 3

Terracotta Toolkit In A DSO Application

I’m not going to go into any details here, but a DSO application is one in which you’ve configured your application’s boot process to use some special Terracotta jar files to do the actual boot-up, and you’ve configured an <application> section of an XML file to tell that custom boot process how to instrument your code for clustering.

In the application’s Terracotta config file (usually called tc-config.xml), you specify three primary things: 1) which classes you want instrumented, 2) the roots of data structures you want to share (cluster), and what parts of your code should be configured for shared locking.

It turns out that you CAN mix DSO and Terracotta Toolkit use.  To do so, you only do two things differently:

  1. You instantiate the class TerracottaToolkit instead of TerracottaClient
  2. You link against the file “terracotta-toolkit-1.0-1.0.0.jar” instead of “terracotta-toolkit-1.0-runtime-1.0.0.jar”.  The former contains the TerracottaToolkit class while the latter does not.

The TerracottaToolkit class’s constructor takes no arguments.  It picks up its configuration details from the already up and running Terracotta client environment established via the DSO startup process.  So here’s what it looks like in the DSO case to get a Toolkit instance:

ClusteringToolkit toolkit = new TerracottaToolkit();

This entry was posted in Uncategorized. Bookmark the permalink.

1 Response to Using the Terracotta Toolkit standalone vs inside a DSO application

  1. Mark Hoffman says:

    I can’t seem to lock this jar file “terracotta-toolkit-1.0-1.0.0.jar”, only the runtime version. Any pointers where to find it?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s