Manik Surtani is a core R&D engineer at JBoss and project lead on JBoss Cache. He has a background in artificial intelligence and neural networks, a field he left behind when he moved from academic circles to the commercial world. Since then, he's been working with Java-related technologies, first for a startup, focusing on knowledge management and information exchange. He later worked for a large London-based consultancy as a tech lead focused on e-commerce applications on large J2EE and peer-to-peer technology. Manik is a strong proponent of open source development methodologies, ethos, and collaborative processes, and often speaks at Java User Groups around the world. Manik is a DZone MVB and is not an employee of DZone and has posted 39 posts at DZone. You can read more from them at their website. View Full User Profile

JSR-107 and a JSR on Data Grids

02.16.2011
| 5095 views |
  • submit to reddit

In 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

What JSR-107 does not cover - but should be included in a Data Grid JSR
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
These could be useful in the JSR, but needs more thought and discussion
  • An asynchronous, Future-based API (See Infinispan's Async API)
  • XML-based config file standardisation (including an XSD)
  • Standardise programmatic config bean interfaces

Further interesting thoughtsThese additional, NoSQL-like features would also be very interesting, but probably more sense in a later revision of this JSR - both for the sake of manageability as well as to allow more community adoption/feedback on such APIs.
I'd like to hear your thoughts and opinions around this - please comment away!
CheersManik

 

From http://infinispan.blogspot.com/2011/02/jsr-107-and-jsr-on-data-grids.html

Published at DZone with permission of Manik Surtani, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: