Pure Danger Tech


navigation
home

JSR 107 and proposed data grid JSR

14 Apr 2011

I was interested to read Manik’s new proposal for a data grid JSR to be based on JSR 107 (the long dormant caching JSR) and some of the ensuing discussion.

[I am a former Terracotta employee but have not spoken to anyone at either Terracotta or Red Hat about this; these are my own opinions.]

On the meta story about FUD blah blah, it seems pretty obvious to me that a) this is a hot area, b) there are multiple players each with viable commercial solutions, c) there is a lot of money at stake, and therefore all the players are going to get excited about their involvement in any possible “standard” (and that includes both 107 and the proposed spec). A standard, especially one that could be part of Java EE (for those people that still care about it) has the potential to both open the exposure and limit feature sets for all of these vendors. Of course they will be scrapping for influence and control.

Back on the actual JSRs, JSR 107 has been around for a long time but never finalized. Do people care? The basics of most cache APIs are pretty simple (they look mostly like maps plus additional config for eviction) and it’s relatively easy to switch between them already. If this JSR was important to commercial users, they would have been pushing for a standard but 107 has been basically dead for years due to lack of interest. As a spec itself, 107 is pretty weak; I’d much rather use the real APIs of any of the current caching vendors directly rather than dumb down to the lowest common denominator required by a caching spec.

However, in the distributed caching space, the various vendors have all been evolving and competing at a rapid pace for years. Once you start talking about JTA integration, write-through, write-back, distributed loading, partitioning, async/blocking models, etc there is a lot of differentiation both in features and API. A few years ago I’d say those were divergent trajectories, but I think in the last year or two the feature sets are starting to converge. Maybe that’s a good sign that a standard would be a useful forcing function for determining a core set of distributed caching functionality.

There is still a lot of variability between vendors so I’m not sure how easy it would be to standardize the various common features and also include extensions for vendor-specific features. Apart from the most obvious players in this (Terracotta, Oracle, GemStone, Red Hat, etc) it seems like there are lots of nosql vendors that might also want a crack at it (CouchBase, MongoDB, etc). I would be very curious to see an API that let both of those communities highlight their strengths. That seems challenging.