For the past couple of years I have been saying that ehcache will never be distributed. Ehcache grew out of uncommitted patches to the Apache JCS cache. JCS implemented the JCACHE JSR. It had lots and lots of features. The reason for the patches was that the in-memory and disk stores had memory leaks and threading problems.
The idea of ehcache was to bring it back to something very simple and then get all the kinks out. Ehcache has been successful in achieving that aim.
Over the last year there have been feature requests and offers of help to implement those features. Surya Suravarapu in particular volunteered for one day a week. He was very keen to make ehcache distributed. We decided to start our collaboration with something more prosaic: some new cache policies. He added FIFO and Least Frequently Used. In its latest incarnation it has become Less Frequently Used, for performance reasons, which is an interesting story in itself.
Steve from jofti.com then requested event listener functionality. He agreed to give input into the design and review its implementation. After a few iterations we got that done to his satisfaction and it is now being used from his Jofti cache indexer and search library.
Paul Hammant and Jo Walnes took a look at ehcache during OSCON2005. They argued that the singleton CacheManager was evil and should be replaced by constructor-based instances, for which it is the callers responsibility to maintain references. I agreed with that and so added the functionality, with a few safety provisions to prevent disk store collisions. The feature turns out to be particularly useful in testing distributed caches on a single machine.
At the conference I ran into James Strachan. James is one of the JCACHE people and the prime mover behind many projects, including the notable ActiveMQ. We discussed distribution and how it should be done. He agreed with me that multicast was fine for discovery but not for delivery. Then I ran into the guys from Sourcelabs, who are keen ehcache enthusiasts and may offer support for it. They were saying I really needed to make it distributed. There voice is of course added to the many requests for the same feature.
These ideas bounced around for a while. I was also doing some architecture work for a distributed system at the time. I had also been doing lots of reading on distributed system. In August I decided to commit the time to make it happen.
I was keen on doing it test first and keeping it as simple as possible. I decided to start with the primitives in the JDK and see where that took me.
One thing that quickly emerged was the disparate views on what makes for the best distribution mechanism. Surya was keen on a JGroups approach. Another group at BNP were interested in a JMS based approach. To accommodate these needs I decided to make the distribution framework pluggable. I am interested in using ehcache as a test bed to explore different distribution ideas. Of course, it takes at least two implementations to make sure you have your plugin framework right. I have two for discovery and one for delivery right now. Hopefully another delivery implementation will get done that can prove or force modification to the framework.
A lot of hard work and 5 months later and ehcache 1.2 beta 3 is out with distributed caching built-in. Thanks to everyone who lent a hand.
I now want to get it in the hands of as many people as possible and get the bugs out. I need to do further documentation. I need to see how distribution can best be utilised for applications like Hibernate and web pages. Ehcache-1.1 is now 13 months old. An update will be timely.
The funny thing is, ehcache now had a similar feature set to the original JCS. Perhaps it would have saved me a lot of time and effort if the JCS developers could have just accepted the patches I put in two and a half years ago.
