I’m intending this as a piece of advice that is (hopefully) helpful to both of us. Helpful to me because, if you write the article I want, then it will make my life as a product selector a lot easier. And hopefully helpful to you, because if you make it easier for people to know what your product can do for them, then they’re more likely to buy it, and you’re more likely to stay employed :)

I think Terracotta is a great piece of technology, and I always keep it in the back of my mind as an option for future systems I build, but, like Casper, I’ve never quite got a good handle on what it can do for me.
As a (mostly former) Jetty developer, I know that it can give me session clustering for Jetty if I ever need that. But that’s about as far as it goes. I suspect the only reason that makes a lot of sense to me is because I know Jetty really well, and I know other servlet containers pretty well, so I know what Jetty+Terracotta adds over Jetty on its own.

But, that’s as far as it goes for me.

This blog entry, takes a fairly common approach of starting with the technology, and then expanding that into a use case.
That’s not surprising – you’re a technologist, and this is your personal blog, so it reflects your mindset.
But I’m your reader, and in this context, I’m not a technologist, I’m a potential user.
(Sure, in another context I’m a technologist, but just getting my exciting about the technical merits of Terracotta isn’t going to turn me into a user)

See, I look at this description and think “so, if I’m already trying to run something across multiple VMs, Terracotta can make some of that work a bit better”. It feels like I have to have walked myself into a bit of a mess (a cluster of VMs without shared data, or a cluster of VMs with an inefficient way of sharing data) before Terracotta has much to offer me.

But I suspect that’s not the full story. I assume there are problems that I’m trying to solve, where I might previously have used a single VM, where Terracotta would allow me to use a cluster of VMs without all the head-aches. Or maybe I don’t even need to think about it as a cluster, but instead just think about it as “replicated/resilient memory”.

The stories that would catch my attention would be the ones that start with a problem that needs to be solved. So your user registration codes would start with: “Are you persisting small transient objects to the database just to provide a resilient backing for your data? Terracotta can allow you to keep it all in memory on your VM, while still giving you the resilience you’re looking for.”

Start with the user – what problem are they trying to solve?
Then, how can Terracotta be used to solve that in a “better” way than the typical solution people would use?
That’s the sort of description I’d read and buy into.

There are couple of more Use Case that I see
1. Generating unique Id for tables (typically this headache is left to Database). AFAIK, Terracotta makes it pretty easy

2. DB caching is good, but still we have the overhad of talking to DB, including Network IO, so if we have a cache, we gain a lot. I don’t think there is one on one comparison between a DB cache and Terracotta based cache

3. Guess Terracotta bases clustered POJO can easily act as Singleton in clustered J2EE environment

The distributed processing using LinkedBlockingQueue is master piece, processing data across JVM’s was never this simple. I believe Terracotta has much more potential Use Cases, than what I have listed :-)