POJO Mojo

Terracotta is all about Java--clustering and caching Java apps as late in the cycle as post-deployment or as early as during design. We enable developers to write to one VM, scale to many. And we provide a simple development model--writing for one VM as if you were building a prototype--for distributed computing yet we inject powerful RAS characteristics at runtime. For Terracotta, clustering is more than just clustered caching.

We share data and coordinate that sharing. With just the JDK, nothing new to learn, no new code to edit, and no APIs to navigate. You could say we've got serious POJO MOJO. And, I am really excited about where we plan to take this technology. Terracotta has a vision for what I call the ultimate in runtime control--a topic for another time. How did we come across this view? This approach?

This article is the first in a three-part series of articles which examines how Terracotta DSO preserves object identity and how it is a key differentiator as compared to traditional API-based cache services.

• Part 1 explains what object identity is and why preserving it in a distributed cache is important.
• Part 2 examines how domain modeling suffers when object identity is not preserved.
• Part 3 illustrates how DSO preserves identity in a sample application.

Updated October 2006 for Terracotta 2.1

DSO is the transparent “Distributed Shared Objects” component of the Terracotta Server. It is an API-free way to convert a multi-threaded application to a multi-VM application, as well as a drop in session clustering tool for WebLogic. If this is your first time working with the DSO product, I recommend downloading the product from http://www.terracotta.org and working through the "Hello World Tutorial" and trying out the sample applications.

A common problem I run into when writing Distributed Applications is coordinating actions. Recently, while using DSO to write a Distributed Performance Test, I encountered this very issue. I wanted to start N nodes, have them wait until all N reach the point of load creation, and then simultaneously send load to the server.

The problem of managing conversational state (i.e. HttpSession) within a clustered web application is fairly well known. A clustered application that relies on the use of session data must have a robust and efficient session layer underneath it. The standard approach is to provide some form of data replication to another node(s) or to a database (gasp). All of the major application server vendors (and a few 3rd party products) provide mechanisms to enable data replication, BUT developers need to keep a fair number of constraints in mind when designing with these solutions (in no particular order):

• If the state of any object referenced by a session is modified, a call to setAttribute() is required to inform the system that replication is necessary
• Objects placed into session must implement java.io.Serializable and thus inherit the standard issues associated with serialization (performance overhead, versioning, duplicate instances upon de-serialization, etc)
• Session data may not be globally available within the cluster (depending on the replication model)
• Replicating data to other nodes has a significant impact on performance and memory usage
• Session replication is usually only available in higher priced “enterprise” or “cluster” editions of certain products

This article is the second in a three-part series of articles which examines the notion of object identity in a distributed cache. Terracotta DSO preserves object identity; traditional API-based cache services don't. This is a key differentiator for Terracotta and a big win for developers.

• Part 1 explains what object identity is and why preserving it in a distributed cache is important.
• Part 2 examines how domain modeling suffers when object identity is not preserved.
• Part 3 illustrates how DSO preserves identity in a sample application.

I recently had a chance to spend time with a major enterprise software vendor's R&D leaders. They have been closely watching Terracotta and our space. The VP of Engineering for this company summarized the space by saying, "Terracotta's competition leaves correctness as an exercise for the reader."

I think it comes down to scalability versus correctness. Fundamentally, we cannot sell "Enterprise Software" until we have something with which a developer or operator cannot shoot themselves--we call this "do no harm." But, performance vendors offer up tools that enable asynchronicity, and potential race conditions. Do correctness and scalability, therefore, conflict? Is it just too expensive to get a clustered lock from a network resource and should I thus allow "last one in wins" semantics? Well, the answer is mostly no. I should not dictate such semantics. I should not offer up a tool for scalability that focuses on "fast" in exchange for "right."

In this article I will explore the shortcomings of a speed-centric API-based approach and offer up an explanation of what Terracotta does instead that I think is both more correct and, thus, useful in your day-to-day task of building highly reliable and scalable business applications. I start with some assertions that we believe are fundamental to helping you get your job done. In a follow up blog entry, I will then add some color through retelling a few of our experiences out in the market to help validate my claim that we can provide correctness without sacrificing scalability.

My assertions

1. API-based caching helps with only part of the problem
2. APIs are unnecessary AND harmful because they add complexity (much like memory management used to be an API but has been factored away)
3. API-based caches violate basic engineering principles: tuning during design is just too hard
4. API-based caches do not address the complexity introduced by caching the database

Developers of enterprise software have both the best and worst job in the world. While they are prototyping or developing core business functionality, they live in a world of logic – a world they create by themselves where they are completely in charge of the rules. This dream is shattered, however, when they have to deal with the underlying infrastructure services that are necessary for their applications to perform well or scale beyond their workstation – services like caching, or clustering the app to run on more than one server. The promise of managed runtimes like Smalltalk, Java, or C# - that the runtime will take care of the underlying plumbing – has not yet been fulfilled. Ask any developer how much of his or her code is taken up with infrastructure code (typically 20-40%!) and it’s obvious that the “managed runtimes” have a ways to go before delivering their utopian ideal.

This is the last in a three-part series of articles which examines the notion of object identity in a distributed cache. Terracotta DSO preserves object identity; traditional API-based cache services don't. This is a key differentiator for Terracotta and a big win for developers.

• Part 1 explains what object identity is and why preserving it in a distributed cache is important.
• Part 2 examines how domain modeling suffers when object identity is not preserved.
• Part 3 illustrates how DSO preserves identity in a sample application.

Overview

In part one of this series, we explored the notion of object identity and why it is an important consideration in developing distributed applications. In part two, we saw how most traditional replication frameworks do not preserve object identity and how this in turn can have perverse effects on application design. By contrast, Terracotta's DSO framework can be used to distribute an application in a way that is completely natural.

Now, we are going to explore in some detail how that natural model is presented to the developer. We will write some simple code that demonstrates how a developer using DSO can develop a domain model without having to worry about how it will behave in a distributed operational setting. The operational concerns come later, in a second step which involves making some simple declarations in XML.

After spending the last several years running the JRockit JVM business at BEA and the last year working closely with Terracotta's customers and partners, it has become totally clear that there are two big galactic forces in Java today - namely: scale-out and complexity - and these two forces are actually conflicting with each other and reinforcing the difficulties facing Java developers and application operators in the market today. Layered on top of this is the need for the managed runtime (the JVM) to handle more of the operational responsibilities in Java applications today (see my previous post on Developer vs. Runtime Responsibilities). Let me explain myself a bit more clearly:

Several people have commented to me, and have posted links to my latest blog posting effectively twisting my words around to make the point that Spring was not designed for scalability. Nothing could be further from the truth.

Colin's blog posting says it better than I can - and yes, he is right, I "deserve a spanking" and should know better.

We at Terracotta believe strongly that the Spring framework vastly simplifies the task of creating enterprise applications by, among other things, adhering to some basic principles such as application code should not have any unnecessary dependencies on the underlying infrastructure, and that many infrastructure related tasks can and should be taken care of transparently at runtime. The point I was trying to make (somewhat awkwardly) in my post was that scalability (ie. sharing of state and behavior between nodes in a cluster) should follow those same principles. This is not the full definition of scalability, of course - a completely stateless application can scale very nicely without the need to share in-memory state or behavior between nodes. But, in the cases where state and/or behavior needs to be shared or coordinated between nodes, a Spring application can scale very nicely in conjunction with any number of other products, such as WebLogic Server, Tangosol's Coherence, or our product, Terracotta. In my post, I was drawing a contrast between scalability and simplicity, and in this context, the combination of Spring and Terracotta makes the most sense to us - it achieves the desired scalability (sharing of state/context/behavior) without making the application more complex by requiring dependencies on the underlying infrastructure. Terracotta, like Spring, is transparent and API-free - thus the very natural partnership between Spring and Terracotta.

I hope this clarifies our position somewhat - comments welcome!

To demonstrate how to use DSO in distributed computing projects, I have written a small demo that computes and displays a Mandelbrot fractal. I assume you have some knowledge of our product, but if not, it would be helpful if you download http://www.terracottatech.com/downloads.jsp and check out our other demos first. Our product guide

http://www.terracottatech.com/product-docs/product-guide/toc.html

is also a great start.

You can read more about the Mandelbrot set here:

http://en.wikipedia.org/wiki/Mandelbrot_set

http://www.devx.com/Java/Article/32603

This article covers my basic thinking on how to keep transient data out of the database. I do believe that domain data will, for the forseeable future, belong in the database. But I simultaneously believe that transient data doesn't belong there. In the article, we avoid talking about a particular product and instead talk about the concepts and what it will take to simultaneously deliver the value of stateless while coding to a stateful model. I hope people find it worth the read.

Traditional approaches to session clustering incur a significant performance hit due to the overhead of serializing objects. Terracotta avoids serialization and instead clusters by replicating only field-level changes to objects and additionally only replicating changes out to the application nodes as the changes are requested.

In our most recent performance tests, 6 Tomcat nodes clustered with Terracotta Sessions sustained over 7,000 TPS compared to about 2,000 TPS for 6 nodes clustered with Tomcat's built-in "Pooled Mode" clustering. For the detals, see the Terracotta & Tomcat Sessions white paper at: http://www.terracottatech.com/documentation.shtml

I spent last week with Floyd and crew at QCon 2007 in London. The conference was highly energized and lots of brilliant people were hanging out discussion Java and real application design. It was very refreshing to not talk as much about "the future" and whether or not Java is dead and about new languages in the runtime. There was a strong return to use cases and pragmatic advice for the architect and lead developer.

Read on for my summary...