Interview

Q&A – Greg Luck, CTO Ehcache at Terracotta talks about javax.cache (JSR 107)

Chris Mayer
ehcache

We get the latest developments behind Oracle and Terracotta’s cooperation towards creating a standard API for caches

Can you explain the idea behind
javax.cache and how it fits into the Java ecosystem?

The simple idea behind javax.cache is
to have a standard API for caches. A cache is a temporary store of
data. Caches are now widely used for performance, scale up, and,
with distributed caches, scale out.

The spec requires Java 6 or higher. While it will
be included in Java EE 7, it can easily be added to existing Java
EE 6 and Spring containers, along with existing Java SE
applications.

The javax.cache package, as defined by JSR107, is a complement
to JPA. While JPA is about persistence, JSR107 is about temporary
storage of objects likely to be reused. With that in mind, we have
been ensuring the spec harmonises with approaches taken in JPA
2.0.

Can you give us a few details behind its
unique features?

The basic concept is a CacheManager that holds and
controls a collection of Caches, which in turn have cache entries.
A cache entry has a key and a value.

Functionally, the cache API can be thought of as
similar to a Map with the following additional features:

  • atomic operations, similar to java.util.ConcurrentMap
  • read-through caching
  • write-through caching
  • cache event listeners
  • statistics
  • transactions including all isolation levels
  • caching annotations
  • generic caches, which hold a defined key and value type
  • definition of storage by reference (applicable to on heap
    caches only) and storage by value

How important do you believe it is to standardize
caching for the community?

The Java community has always prized standards.
The ability to switch out one implementation for another has always
been very important and is one very significant difference between
the Java community and .net. 

So whenever you have a proliferation of
implementations around a set of features, it is natural to want to
standardise it. Oracle kicked off the idea of JSR107 originally but
didn’t have its own cache until the company acquired Tangosol
several years ago. And in 2009 Terracotta acquired Ehcache. As a
result, we had two corporations able to fund development of the
standard.

How long has this been in development for
Java EE 7? Any issues along the way?
 

We kicked it off properly in March after getting
support from JSR342, the expert group
doing Java EE 7. They definitely provided the trigger to get things
moving. 

Things have been going smoothly. A lot of new
members have joined the Expert Group. We now have 19 members. As
you would expect, we have most of the Java caching vendors. But we
also have some corporate members such as Goldman Sachs, Citigroup,
and some leading individuals such as Eric Dalquist who pioneered
caching annotations.

Obviously, Terracotta and Oracle have
teamed up for this project. Has the relationship between the two of
you going smoothly?

Sure. Cameron Purdy and I have always had cordial
relations. Cameron appointed Yannis Cosmadopoulos, a senior Staff
Engineer, to be co-spec lead in his place. Yannis and I have a lot
of debates but also socialise too. I have been working out of
Oracle’s San Francisco office when I am in town and we always go
for lunch. I even get invited to the Friday drinks.

Both Oracle and Terracotta share a willingness to
be flexible on the licensing. The reference implementation is
Apache 2 as are the TCK tests. The whole TCK will be a custom
license with a few variations on the standard TCK license. In
particular, it will be free and open source friendly.

A lot of vendors have interest in
implementing JSR107. Is there anything that Terracotta’s Ehcache
offers that the others don’t, or is it fairly standardized across
the board?

The API is standardised, but the capabilities will
vary widely by vendor. Also some parts of the API are optional:
transactions, store by reference and annotations. 

On the capabilities side of things, there is much
to differentiate vendors:

  • Is the cache standalone or distributed?
  • Does it support the optional features?
  • What is the performance of the implementation?
  • Are tiered cache stores supported?
  • Can the cache be made persistent?
  • Does the cache support search?
  • How much data can be put in a cache? In a JVM? Per cache
    storage node?
  • Does the cache support a rich set of data consistency models
    (e.g. eventual consistency and strong consistency)?
  • Are caches highly available? Are they resilient?
  • What frameworks does the cache plug into (e.g. Hibernate, Web
    Caching, Grails, JRuby, HTTP Sessions)?
  • Can distributed caches be operated over the WAN? What
    modes?

In general, there are two classes of cache
implementation: open source ones, which don’t do most of the above,
and Enterprise Caches, which support these capabilities to
different degrees. Enterprise Ehcache fully supports all of these
capabilities.

In addition, Ehcache has been for many years the
de facto industry standard. More recently, we have created some
breakthrough features. We can store hundreds of GBs in each cache
node all in memory with our BigMemory technology. We provide the
ability to search caches. And in our most recent release, we
dramatically simplified our configuration with Automatic Resource
Control, which allows caches to automatically allocate their heap
and off-heap memory usage.

You recently spoke about the entire
project with Cameron Purdy at JavaOne – what reception did you
receive from the people at the conference and did they offer any
feedback at all?

The session was full. There was and is a lot of
interest in JSR107. I think people liked what they saw, but most
people outside the expert group still want to take a close look at
it.

As a sign of the level of interest, I just gave an
updated talk on JSR107 at Devoxx last week and will be giving
another talk at Jfokus in February. I plan to show off Ehcache 3.0,
which will provide a native implementation of the spec.  

How close are we to seeing JSR107
finished?

I think we are close. Yannis and I finished up the
baseline spec about a month ago, and it is now getting revised
based on review comments. Both Oracle and Terracotta are working on
implementations, which is further driving fine-tuning of the
spec. 

My hope is that we will get a complete JCP first
draft done by end of year.

What are Terracotta’s plans for the
future, in relation to JSR107?

We will have two implementations. The first is a
wrapper, which will work with the current Ehcache 2.5 release. It
is in beta now and implements all features other than transactions.
(Ehcache supports READ_COMMITTED XA and Local transactions, but
under the spec you must provide all isolation modes if you claim
transaction support.)

Secondly, the next major version of Ehcache will
plan to natively support the API. By this I mean that we will have
a Cache class, which will both implement javax.cache.Cache and will
also interact with our code in the most efficient way possible. We
will likely also continue to support the existing Ehcache API for
backward compatibility. 

We plan to get this done early next year and be
first to market.

Author
Comments
comments powered by Disqus