Friday, November 5, 2010

A Couple Minutes With Ehcache Search...

Welcome To Ehcache Search

Now that we are releasing our, GC Busting, Ehache BigMemory product we are starting the process of gathering feedback on the new Ehcache Search API. While Ehcache Big Memory solves your Latency, through-put and SLA issues, Ehcache Search gives you the ability to handle a users data retrieval needs in a simple and efficient way.

What is it?

With todays data explosion and hardware memory size explosion, in-memory and caching have become an important part of everyone's software. Now, getting at the data in that cache in a flexible, simple and fast way has really become an important area of focus. Things like finding entries that match criteria, performing aggregations and calculations (eg average, sum, max, min) need to be easy and efficient.

That's where the new Ehcache Search API comes in. It will provide fast efficient searches and aggregations across the Ehcache Snap in, Speed up, Scale out continuum (Single node performance through scaled out architecture).

Please try out the API (It's checked into Ehache core's trunk) by grabbing the this self contained, buildable sample and open source Ehcache nightly jar I've put up on GitHub.

It's simple to use and 100 percent open source. We are very excited about feedback and plenty of time still exists for making changes and improvements. Please ask lots of questions and give lots of feedback.

To try it you can just unpack the kit:

tar -xzvf ehcache-search-sample-0.0.1-SNAPSHOT-distribution.tar.gz

and run it:


The source code is included in the kit and can be edited in this directory:


rebuilt if you have Maven.

mvn clean install

And rerun using the command.

You can even package it up yourself by using

mvn clean assembly:assembly

Looking forward to hearing from the community. It will be interesting to see how projects like Grails, Hibernate, Liferay and Cold Fusion leverage cache search. Those uses will help set direction for years to come.


  1. I haven't tried this yet, but I assume that JPA objects placed into the cache would be searchable also? Probably give it a try later today and post back... inquiring mind wants to know...

  2. Yep. All of our config is at the cache level. We don't actually care what kind of cache it is. So it will work.

  3. Can ehcache search be seen as a competitor to lucene, solr and bobo? Or is it missing something? I actually like the simple programmable api without having to think to hard about all this index stuff :-)

  4. I hadn't really thought about it that way. Ehcache search's goal was to be a simple to use highly scaleable HA distributed cache and a query mechanism for accessing that cache. That's the angle we approach it. I guess one could argue that solr does a similar thing for indexes so in that regard they can be somewhat competitive. I still don't think of them as competitors except on the fringes but one of the cool things about new products is you never know where they will lead.