Infinispan team is coming to São Paulo (Brazil) to present on multiple topics around caching, data grids and NoSQL in Brazil’s first ever JBoss Users & Developers Conference (JUDCon). The event is being held over two days, on 19th and 20th of April.

On the 19th, Manik Surtani and Pete Muir will present on how to supercharge web applications using JBoss Data Grid. Expect a very lively presentation from these very seasoned presenters :)

Another presentation where you’ll be able to see Infinispan in action is in Shekhar Gulati’s "Closed PaaS to Open PaaS : Migrate GAE Applications to OpenShift Using CapeDwarf" and Randall Hauch’s "Elastic Consistent NoSQL Data Storage with ModeShape 3" talk, both on the 19th of April, where Shekhar and Randal will demonstrate JBoss projects using Infinispan heavily.

On 20th of April, I’ll be speaking about scaling up Hibernate/JPA applications with Infinispan second-level cache. Even if the Infinispan caching provider was created almost 4 years ago, this is the first time I’m presenting about it. Really looking forward to that.

Finally, I’ll also give the first ever presentation on Infinispan JCache (JSR-107) API implementation, which will be mostly a live coding session showing different bits about JCache API and the extra capabilities JCache users get from using Infinispan implementation.

Cheers, Galder

Happy new year, everyone.

One of my goals for 2013 is to push JSR 347 into action again.  To kick start this, I propose a meeting among expert group members - anyone else with an interest in the JSR is welcome to attend as well.

Details are in my post to the mailing list.  Please respond to the mail list if you are interested in participating.

Cheers Manik

Infinispan Arquillian Container is an extension to Arquillian that provides several ways to interact with Infinispan, either with a standalone Infinispan server or just with Infinispan libraries. This extension can also communicate with JBoss Data Grid server via JMX.

It was released as Maven artifacts in JBoss Maven Repository. It is located at http://repository.jboss.org/nexus/content/groups/public-jboss/ . More information on how to set up and use the repo can be found at https://community.jboss.org/wiki/MavenGettingStarted-Users

What does this Arquillian extension offer to you? Let me describe all aspects of this extension one by one.

PCWorld has published an article on the recent data grid JSR that I have submitted.  As a follow-up to PCWorld’s article, I would like to make a few comments to clarify a few things.

I don’t quite understand what is meant by Red Hat’s approach not being the best solution.  Do people take issue with having a standard in the first place?  Or is it the standards body used in this particular case (the JCP)?  If it is the details of the standard itself, one should keep in mind that this has yet to be defined by an expert group!

It is unfortunate that the "others" mentioned in the article - who feel that Red Hat’s approach is not the best - were not able to provide any details about their objections. I would love to hear these objections and make sure that the JSR addresses them.

The importance of a standard, to remove vendor lock-in, etc., is pretty well understood, so I won’t go into too much detail here.  But with that in mind, I find Pandey’s comment regarding a "self-beneficial move" an odd one.  A standard makes it easier for people to switch between products (which may explain why no one else may have stepped up to the plate to propose such a standard thus far).  Proposing a standard makes it easier for end-users to move away from Infinispan.  Yes, it may help with awareness of Infinispan, but it also means Red Hat, just like other data grid vendors, will need to work really hard to make sure their products are up to scratch.  The only real beneficiary here is the end-user.  In fact, I’d like to invite Terracotta to participate in this JSR, as participation can only make it stronger, more relevant and eventually even more useful to end-users.

With regards to JSR-107, I believe Pandey has misunderstood the intention in proposing a data grid JSR.  I have proposed extending and building on top of JSR-107 - not throwing it away - and I have expressed this the JSR-107 expert group mailing list, of which Terracotta’s Greg Luck is a member.  In fact, without Pandey’s actually seeing my data grid proposal blog post - PCWorld’s article was written before I published details of the JSR submission, based on a high-level Red Hat press release - one has to wonder where such strong words come from!  :-)

Cheers Manik

Following up on my previous response to Antonio Goncalves' blog post, I have submitted a JSR to the JCP on a data grid standard, titled "Java Data Grids".  It has yet to be assigned a number by the JCP, but I thought I’d talk about it a little here anyway.

Here is the description of the JSR that I have submitted:

Data grids are gaining prominence and importance in enterprise Java, particularly as cloud-style deployments gain popularity:

With one of Java EE 7’s stated goals being "cloud-friendliness", the above are powerful arguments for the inclusion of a distributed data grid standard in Java EE 7.

What about JSR-107?  JSR-107 - the temporary caching API proposed in 2001 - certainly has a role to play in Java EE too.  Temporary caches are an important part of enterprise middleware, but yet a standard has been sadly missing from a Java EE umbrella specification for far too long.  Spring, having identified the need as well, has a temporary caching abstraction in their current development versions.  Several other non-Java frameworks define temporary caching APIs too (Ruby on Rails, Django for Python, .NET).  There is no denying JSR-107 is necessary, and necessary as a part of Java EE.

But JSR-107 isn’t a data grid.  JSR-107 falls short as a standard for data grids, specifically as it doesn’t take into account characteristics of distribution and replication of data, and doesn’t define a contract that implementations would have to adhere to when it comes to moving data around a cluster.  Crucial things for a data grid that, if not baked into a specification, will hinder portability and render the standard itself useless and impotent.

Further, with remote capabilities in mind, a data grid should also expose a non-blocking API, since network calls can be a limiting factor.  Invoking methods that involve remote calls should be able to be done in an asynchronous fashion.  Stuff that is irrelevant to a temporary caching API like JSR-107.

So with all that in mind, I’d love to hear your thoughts on the data grid JSR.  In addition to Red Hat, the JSR is currently backed by a major Java EE and data grid vendor which cannot be named at this stage, along with independent JCP members with relevant interest and background.

Cheers Manik

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:

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

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

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.

I’d like to hear your thoughts and opinions around this - please comment away!

Cheers

Manik

Last month, at the JavaOne conference in San Francisco, I spoke about data grids.  A BOF session on on cloud-ready data stores using data grids, and a conference session on measuring performance and benchmarking data grids.  But in addition to the official JavaOne talks, I also did two short, 20-minute mini-sessions at the Red Hat booth at the JavaOne pavillion, titled Data-as-a-Service using Infinispan.  The good folks at the Red Hat booth even recorded it and put it online on Vimeo, where it is accessible on-demand.

Data-as-a-Service using Infinispan from JBoss Developer on Vimeo.

Enjoy, Manik

I will be presenting on Infinispan, data grids and the data fabric of clouds at JBoss World Chicago, in September 2009. I will cover a brief history of Infinispan and the motivations behind the project, and then talk in a more abstract manner about data grids and the special place they occupy in providing data services for clouds.

In addition, I expect to pontificate on my thoughts on clouds and the future of computing in general to anyone who buys me a coffee/beer! :-)

So go on, convince your boss to let you go, and attend my talk, and hopefully I’ll see you there!

Cheers Manik

Over the past few months we’ve been flying under the radar preparing for the launch of a new, open source, highly scalable distributed data grid platform. We’ve finally got to a stage where we can announce it publicly and I would like to say that Infinispan is now ready to take on the world!

The way we write computer software is changing. The demise of the Quake Rule has made hardware manufacturers cram more cores on a CPU, more CPUs in a server. To achieve the levels of throughput and resilience that modern applications demand, compute grids are becoming increasingly popular. All this serves to exacerbate existing database bottlenecks; hence the need for a data grid platform.

So why is Infinispan sexy?

What are data grids?http://www.arcatoglobal.com/images/ag_serverfarm.jpg[]

Data grids are, to put it simply, highly concurrent distributed data structures. Data grids typically allow you to address a large amount of memory and store data in a way that it is quick to access. They also tend to feature low latency retrieval, and maintain adequate copies across a network to provide resilience to server failure.

As such, at its core, Infinispan presents a humble data structure. But this is also a high specialised data structure, tuned to and geared for a great degree of concurrency - especially on multi-CPU/multi-core architectures. Most of the internals are essentially lock- and synchronization-free, favouring state-of-the-art non-blocking algorithms and techniques wherever possible. This translates to a data structure that is extremely quick even when it deals with a large number of concurrent accesses.

Beyond this, Infinispan is also a distributed data structure. It farms data out across a cluster of in-memory containers. It does so with a configurable degree of redundancy and various parameters to tune the performance-versus-resilience trade-off. Local "L1" caches are also maintained for quick reads of frequently accessed data.

Further, Infinispan supports JTA transactions. It also offers eviction strategies to ensure individual nodes do not run out of memory and passivation/overflow to disk. Warm-starts using preloads are also supported.

JBoss Cache and Infinispan

So where does Infinispan stand against the competition? Let’s start with JBoss Cache. It is no surprise that there are many similarities between JBoss Cache and Infinispan, given that they share the same minds! Infinispan is an evolution of JBoss Cache in that it borrows ideas, designs and some code, but for all practical purposes it is a brand new project and a new, much more streamlined codebase.

JBoss Cache has evolved from a basic replicated tree structure to include custom, high performance marshalling (in version 1.4), Buddy Replication (1.4), a new simplified API (2.X), high concurrency MVCC locking (3.0.X) and a new non-blocking state transfer mechanism (3.1.X). These were all incremental steps, but it is time for a quantum leap.

Hence Infinispan. Infinispan is a whole new project - not just JBoss Cache 4.0! - because it is far wider in scope and goals - not to mention target audience. Here are a few points summarising the differences:

I have put up some FAQs on the project. A project roadmap is also available, as well as a 5-minute guide to using Infinispan.

Have a look at JIRA or grab the code from our Subversion repository to see where we are with things. If you are interested in participating in Infinispan, be sure to read our community page.

I look forward to your feedback!

Cheers Manik