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:
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 thoughts
These 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.
- Distributed code execution API
- Map/Reduce API
- Querying/filtering API
I'd like to hear your thoughts and opinions around this - please comment away!
Cheers
Manik
Thanks Manik for replying. So, you think it's better to get rid of JSR 107 and create a completely new one, or update it (drastically) ? And what about the spec lead and the expert group ? Will it be (more or less) the same as http://jcp.org/en/jsr/summary?id=107 ? How do you see it in terms of roadmap (when will the JSR be created, when will the expert group get form, will it be possible to follow Java EE 7 aggressive timeframe).
ReplyDeleteThanks,
Antonio
Yes. We did discuss trying to (drastically) update it, but a couple of things leads me to prefer a new JSR:
ReplyDelete1. A data grid is more than a single-VM cache, as proposed by JSR-107. It's conceivable that the EG and general interest group may well be different. For example I see a lot of interest from NoSQL products here.
2. JSR-107 has been inactive so long its created some negative sentiment about it in the community. I think a fresh start is needed.
As for the EG, I expect it to be similar ... perhaps a few people may drop out, but I do expect wider interest, if not in the EG at least in the community of people watching and following the JSR.
I've already proposed this to the JSR-107 EG, and hope to submit a formal request to the JCP by the end of the month. Agreed that EE7's timescales are agressive, but I think this is still achievable as long as we get active enough a group of people on the EG.
- Manik