JSR-107 and a JSR on Data Grids
Join the DZone community and get the full member experience.
Join For FreeIn response to Antonio Goncalves' blog post on his wish list for Java EE 7 and particularly on his comments around the inactive JSR-107 JCACHE spec, I'd like to spend a few moments jotting down my thoughts on the subject.
To start with, I am on the JSR-107 expert group, representing Red Hat.
I have also been in recent discussions with the JCP about the inactive
JSR and what can be done about it.
My feel is JSR-107 needs to be axed. It's been inactive for way too
long, it is out of date, and the community is pretty jaded about it. We
do, however, need a JSR around distributed caches and in-memory
data grids. There is definitely a need in the Java EE 7 umbrella
specification, particularly with increasing focus and alignment with
cloud. Apps designed to scale would almost certainly need a
distributed, in-memory data grid. If Java EE is to be the preferred
platform to build Software-as-a-Service offerings, scalability is
crucial.
So what should this data grid JSR look like? Well, let's start with JSR-107. After all, I didn't think there was anything wrong with JSR-107, just that it was too limiting/simplistic.
What's in JSR-107?
A quick summary:
- Primary interface - javax.cache.Cache - extending j.u.c.ConcurrentMap
- Adds ability to register, de-register and list event listeners
- Defines a CacheLoader interface for loading/storing cached data
- Defines an evict(K) method, as well as the support for different eviction algorithms
- Defines a ServiceLocator approach to loading the appropriate implementation at runtime
- Defines a CacheManager interface to construct and retrieve Cache instances
Over and above what JSR-107 proposed, I believe the following features are crucial to a useful data grid standard:
- JTA
interoperability. The ability to participate in transactions is
necessary, both as an XA resource and as a simple cache to front a
RDBMS, via JPA
- Define behaviour at certain stages of a tx's lifecycle, particularly with regards to recovery
- Should play nice with JPA's second level cache SPI
- Define and mandate REPLICATION and DISTRIBUTION, as well as SYNCHRONOUS and ASYNCHRONOUS versions of network communications
- An asynchronous, Future-based API (See Infinispan's Async API)
- XML-based config file standardisation (including an XSD)
- Standardise programmatic config bean interfaces
- Distributed code execution API
- Map/Reduce API
- Querying/filtering API
From http://infinispan.blogspot.com/2011/02/jsr-107-and-jsr-on-data-grids.html
Opinions expressed by DZone contributors are their own.
Comments