Terracotta is a platform for sharing clustered Java heap. There are many amazing things you can do with it. Too many, in fact. That has sometimes made it hard for me to describe to others why Terracotta is useful – it’s hard for me not to either dive into the details or to go wide and try to describe all possible uses. Luckily, Terracotta usage has expanded quickly enough that we now have a tremendous amount of real data about how people are using it. We can analyze that data to find the sweet spots where Terracotta capabilities are a perfect or almost-perfect match for the problem space.

As a company, we are embarking on a strategic process to focus on a sweet spot, perfect it, and repeat. The goal is to make users in the sweet spot insanely happy and successful. Our starting methodology for doing this is to develop a series of reference applications that we believe are representative of the sweet spots where Terracotta rocks.

We’ll make the reference apps available but more importantly, we will gain some experience in using Terracotta to build semi-real apps. We intend not just to design and build this system, but also to scale it and operate it in production. We will use this experience to distill the design patterns and best practices for using Terracotta in that scenario and provide that material on our web site. We will also flush out any bugs or usability issues and fix them along the way.

The first kind of application we’re going to focus on we refer to as a “user session” use case. This use case involves an application that has some conversational state keyed by user. This state must be available across the application cluster and coherent, yet is not long-term state – it is valid for some period of time (determined by application constraints or session times) and after that can be thrown away.

This is a sweet spot for Terracotta as we are pretty much a perfect match for the requirements. We can provide a transparent API (just write your domain layer like it’s being stored in memory), but still provide availability (by sharing and persisting it), and coherency (due to our implementation under existing Java constructs like synchronization). Using Terracotta for this kind of scenario is a great way to avoid storing and managing that temporary data in your database or clustering for availability through heavier serialization-based mechanisms.

Our first reference application will be an online test-taking application. We will allow users to select and take different multiple choice tests. The “user session” data in this case is the exam data while the test is being taken. The state of the exam needs to be managed but really only the final results need to be stored in a system of record like a database.

We’re still working out the technology stack we’ll be using but the goal is to focus on technologies our customers are already using – Tomcat, Ehcache, Hibernate, etc. I hope to be doing some blogging on our progress as we go.