AMP Cache Performance Tests - JBOSS Cache and Oracle Coherence Cache

AMP is an Alerts Engine which allows sending on request, time-based or event-triggered messages in MMS, SMS or email formats. AMP’s most used and most business critical feature is its ability to send large bulks of messages to their respective subscribers. To accomplish this task while keeping a persisted, distributed and recoverable application state, several key technologies are used and, in some cases, extended:

AMP Persistence Layer

Being a multi-tier enterprise web application, AMP features a robust and well isolated persistence layer which is implemented using Hibernate. In hibernate, each application entity is mapped into one or more database tables, thus linking the relational world to the object world. These entities may or may not be “cached”. The Hibernate API features powerful management of entities and relationships, which is extensively used in AMP’s persistence layer.

Hibernate Level 2 Cache

Hibernate supports three primary forms of caching:

The Session cache is responsible for caching records within a Session (a Hibernate transaction, potentially spanning multiple database transactions, and typically scoped on a per-thread basis). As a non-clustered cache (by definition), the Session cache is managed entirely by Hibernate. The L2 and Query caches span multiple transactions, and support the use of external cache providers.

The L2 cache is responsible for caching records across multiple sessions (for primary key lookups). The query cache caches the result sets generated by Hibernate queries. It is possible to configure a cluster or JVM-level (Session Factory-level) cache on a class-by-class and collection-by-collection basis. In its production environment, AMP uses the class-by-class approach and the JBoss cache as the Hibernate Level 2 cache. The tests performed include testing and comparing the use of JBoss cache or Coherence cache as Hibernate Level 2 cache providers in the AMP application.

Both JBoss and Coherence cache systems provide statistics and other useful configuration and execution values via Java Management Extensions (JMX). Using JBoss JMX console and a browser, one can examine the typical cache statistics (hit/miss rates, hit probability, queue sizes, number of
reads and writes etc…) and witness the cache in action while the application runs.

JBOSS Cache

JBoss Cache is a tree-structured, clustered, transactional cache. It is the backbone for many fundamental JBoss Application Server clustering services, including - in certain versions - clustering JNDI, HTTP and EJB sessions. JBoss Cache can be either local or replicated. Local trees exist only inside the JVM in which they are created, whereas replicated trees propagate any changes to some or all other trees in the same cluster. A cluster may span different hosts on a network or just different JVMs on a single host. Unlike non-cluster-aware caches which may go out of sync when there are concurrent updates, each JBoss Cache instance is aware of remote cache updates and can either invalidate or update its state. JBoss Cache offers a simple and straightforward API, where data (simple Java objects) can be placed in the cache and, based on configuration options selected, this data may be one or all of:

• replicated to some or all cache instances in a cluster
• persisted to disk and/or a remote cluster ("far-cache")
• garbage collected from memory when memory runs low, and passivated to disk so state isn't lost

In addition, JBoss Cache offers a rich set of enterprise-class features:

• being able to participate in JTA transactions (works with Java EE compliant TransactionManagers)
• attach to JMX servers and provide runtime statistics on the state of the cache
• allow client code to attach listeners and receive notifications on cache events

Oracle Coherence Cache

One of primary uses of Coherence is to cluster an application's objects and data. This means that all of the objects and data that an application delegates to Coherence is automatically available to and accessible by all servers in the application cluster, and none of those objects and none of that data will be lost in the event of server failure. At the core of Coherence is the concept of clustered data management. This implies the following
goals:

Near Cache - Provides the performance of local caching with the scalability of distributed caching. Several different near-cache strategies provide varying tradeoffs between performance and synchronization guarantees.

Hibernate and Coherence can be used together in several combinations. These options include using Coherence as a Hibernate plug-in, using Hibernate as a Coherence plug-in via the CacheStore interface and bulk-loading Coherence caches from a Hibernate query.

To provide similar test conditions for all our benchmarks, Coherence will be used as a Hibernate level 2 cache provider.