BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Catching up with Terracotta: Transition to Open Source, Adoption, Hibernate Support

Catching up with Terracotta: Transition to Open Source, Adoption, Hibernate Support

This item in japanese

Bookmarks

Terracotta, provides a JVM clustering solution that can turn single-node, multi-threaded apps into distributed, multi-node apps with no code changes. As reported on InfoQ, the VC backed company went open source at the end of 2006, since then things have taken off. Among the recent developments were version 2.4 supporting Websphere & Hibernate, as well as some high-volume customer adoption of Terracotta, such as by PartyGaming  (producers of PartyPoker.com). InfoQ spoke to Ari Zilka about the transition to open source and Hibernate/Websphere support.

According to Ari, growth has been accelerating fast this year, with doubling of forum posts over the summer, thousands of site visits a week, and over 100 deployed customers. "Terracotta Integration Modules for open source products and frameworks like Jetty, Geronimo, Spring, and Tomcat have been instrumental in this amazing uptick I think". On how going open source has affected the company's growth:
We believe it's been a great catalyst for two reasons. First, it lowers the cost of adoption for users and the cost of sales for us as a company. Customers are now walking themselves completely through a proof of concept and then approach us for a discussion about enterprise subscription after they've seen Terracotta working with their application. This is great for us as it keeps our costs low. This is great for customers as well because it allows them to confirm the value proposition before investing more than their time. Second, there is a powerful signaling benefit to being open source -- having the source in the open is a powerful credibility signal that you know your product is good and able to survive detailed technical scrutiny. We believe this is an especially valuable effect if you are trying to introduce a completely new concept like Terracotta.
On the transition from VC-backed commercial revenue model to open source model:
The transaction cost is much lower for both parties, us and the customer, which accelerates adoption. That is a huge benefit for us and the user community. But at the end of the day the transition is less dramatic than one might think. The core job of a company is to build a product that adds value and then find a way to monetize that product. That fundamental task of making money doesn't change or go away. Open source makes for good products but it is certainly not "free money." The biggest thing that changes is that your number one competitor becomes yourself and you have to find ways to support your community and simultaneously make money. Again, we think this is great for customers because this drives Terracotta to find more creative value-adds than just support. Over the next few months, the community will see what we are talking about.
Terracotta recently announced some notable customer adoptions, including online gambling company PartyGaming, realtime RIA framework Kaazing, and open source CMS vendor Liferay. PartyGaming runs PartyPoker.com, PartyCasino.com, PartyBets.com and PartyBingo.com. The Terracotta deployment will involve clusters of several hundred gaming servers. PartyGaming's CEO said, "Terracotta's ability to cluster hundreds of servers with much lower network utilization than alternative approaches results in very high performance and was a major consideration for PartyGaming."

This past summer, Terracotta 2.4 added support for WebSphere as well as Hibernate. The Hibernate support offers two options, according to Ari:
  • Hibernate second level caching works by clustering EHCache underneath Hibernate. This is for existing apps that just want to lessen the DB load by clustering their DB cache.
  • Hibernate POJO caching works by seamlessly disconnecting and reconnecting POJO's around the cluster to/from Hibernate sessions. Our POJO clustering proxies Hibernate...this is great for new apps (or if someone wants to retrofit), because POJO clustering leads to higher performance through fine-grained field-level updating.
On how Terracotta's field-specific change detection/caching improves upon what Hibernate offers:
In POJO clustering form, it sends less data and it calls Hibernate and the DB less frequently, so it scales better. It is also much easier to work with than Hibernate load() and store() calls sprinkled throughout your code...For 2nd level caching, the key benefit to using Terracotta + EHCache for this is in single-clustering provider IF you are using Terracotta for session and POJO elsewhere in your app. Otherwise, Hibernate 2nd level caching essentially does a custom serialization thing on database rows so a field in the cache is an entire row--it works the same for all caching providers (By the way, this is an example of what people have to hack up and do--in this case Gavin King--when DSO doesn't exist).
Terracotta 2.4 also added support for the re-entrant read-write lock in java.util.concurrent:
Before 2.4, Terracotta could do smarter locking in the cluster than threads in a single JVM could support. While that JVM was pessimistic and exclusive in its locking semantic, we could support so much more out in the cluster where coordination was implemented in Terracotta. For developers who want thread pooling on one machine AND in the cluster, or even just business logic where some threads read and others read/write, re-entrant read-write locks will speed up each JVM in the cluster in a pure POJO fashion. One example of this is concurrentHashMap versus hashmap. Concurrency in the java.util.concurrent collection is enabled via re-entrant read-write locks and is now supported natively inside Terracotta 2.4. More performance!
Ari has been positioning Terracotta as 'Network Attached Memory', analogous to Network Attached Storage (or Network Attached Processing used by Azul).  According to Ari:
This is on purpose. NAS was meant to make file I/O programming simple and to support transparent injection of HA, scalable storage at runtime. Terracotta is designed with total HA in mind (n+m redundancy--as many backups as you want, continuous upgrades with no downtime, etc.). This is important because, while applications are each different, unique and challenging, HA and Scale need to be delivered in a consistent manner for IT to be able to deliver stable low-cost apps to the business. In other words, HA/Scale is a universal need and happens to be what Terracotta is designed to provide when plugged in to Hotspot and now IBM JRE.
For more information on Terracotta, see also InfoQ's previous news coverage and technical articles: http://infoq.com/terracotta.

Rate this Article

Adoption
Style

BT