What Is Terracotta

Network Attached Memory: Purpose Built To Store "Scratch Data"

Terracotta is Network Attached Memory (NAM). NAM is best suited for storing what we like to call scratch data. Scratch data is defined as object oriented data that is critical to the execution of a series of Java operations inside the JVM, but may not be critical once a business transaction is complete. Some examples of scratch data include business workflow state (which step of the flow is the system currently working on), or HTML form data that is being validated by a web application before a database record is created or updated.

The term "scratch data" is derived from students' use of a piece of scratch paper to make interim calculations for a multiple choice examination. This scratch paper is critical to the student during the exam, yet once the final answers are turned in, it is not longer of value to the student or the instructor.

Network Attached Memory

Terracotta coined the term "Network Attached Memory" to explain what our technology does for Java applications. Any Network Attached Memory (NAM) implementation must honor 2 fundamental principles:

NAM must look just like RAM to the application Constructors, Wait / Notify, synchronized(), == and .equals() should all work as expected. An easy way to think about NAM's interface to the application is that an application that supports NAM should run with or without a NAM implementation. For example, if you use a Network Attached Storage (NAS) file server, the application is not aware, nor does it need to be, of whether it is writing to a local or a networked disk. The application itself does not change if NAS is present or not. NAM is exactly the same. If NAM is not present, the application will continue, writing to local RAM. Likewise, the application need not change with the introduction of NAM.

NAM must work as an infrastructure service That is, NAM must run as a driver inside the JVM but also as a separate process apart from the application cluster. This is due to the fact that like networked filesystems, the memory must survive whether or not your application is running. Otherwise, NAM does not provide the true value of connect/disconnect on-the-fly that one would expect when compared to Network Attached Storage.

Terracotta provides Java applications with this powerful NAM concept whereby developers get clustering and high availability because:

1) the memory is shared and external to the JVM, allowing for coordinated cross-JVM I/O, and
2) if the JVM crashes, the data survives any crashes and restarts.

Developers get HA and scale as a result of plugging in NAM.

Terracotta Helps Reduce Database Load

Terracotta allows developers to make finer grained decisions about how to share data than current-state approaches. Without Terracotta, many applications O/R-map or otherwise store Java objects in a relational database. Removing the database dependency in such cases is one way Terracotta simplifies application architecture and development.

In the above image, there is database server and an application cluster with 3 servers. The database should be the size of the dashed black cylinder but it is not only storing System of Record data (labeled SoR in the diagram). It is also working to coordinate between application servers. The application's scratch data is causing the database to get too big for our needs; costs begin to escalate. The red arrows depict the database swelling due to an overload of scratch data.

Terracotta Helps Reduce Development Effort and Dependencies on Application Servers and Frameworks

Alternatively, developers can copy all application scratch data to every JVM in an application cluster, to prevent downtime in case any application servers or JVMs crash. Such approaches can work, but they usually make applications harder to code and maintain. Also, most usually bottleneck on the network long before application logic exhausts the commodity hardware where the JVM is running.

In the above image, the database server is used only as a System of Record (labeled: SoR, with the dashed black lines) because scratch data is now shared using the application tier network. Using some sort of network communication library, developers serialize and copy objects amongst JVMs. Alternatively, those developers use expensive "clustered app server" features to achieve roughly the same result. Serialization and bean-style get() / set() requirements complicate source code. In any case, the red band across the application tier and the associated red arrow depict resultant swelling in source code as well as potential scale-up in hardware capacity needed to support the the clustered application server.

Terracotta's Network Attached Memory Saves Time and Money

Put another way, most application servers are below 30% utilization while the database and network are getting saturated.
With network attached memory as new proper home for scratch data, applications can avoid the problem of ABUSING databases and application servers when trying to store that temporary data somewhere other than in RAM.

Terracotta users find, on average a 10X increase in throughput, and more than 50% cheaper total cost to the application.

Network Attached Memory simplifies application development by providing an external extension to the application heap that stays coordinated across application servers. Developers can now store only System of Record data in the database, and those developers can use any application server they desire, open source or commercial. Furthermore, application memory survives JVM restarts and network attached memory can scale to hundreds of connected JVMs. Most importantly, all data remain Java objects in native Java format, which means developers and architects can choose this approach for almost any Plain Old Java Object (POJO).