POJO Mojo

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