Watch Caching Fundamentals Part 1 by Greg Luck, CTO Ehcache

This is the first in a series of webinars which will explore Caching Principles.

You will learn how to assess the effect that caching to a given performance situation and be able to calculate the performance improvement. Further it will be shown how to tune caches for maximum effectiveness.

This webinar focus on non-clustered caching principles.

The following topics are covered:

– What exactly is caching.
– Locality of Reference, Data lifespans and reuse patterns
– Pareto Distributions
– Amdahl’s Law
– Cache Statistics

Watch the talk here: http://s3.amazonaws.com/tcvideo/2010/Caching%20Principles%20Part%201%20with%20Greg%20Luck,%20Ehcache%20CTO-20100819%201811-1.mp4

Maven Rant: Backward incompatibility and Software anti-distribution

Today I was upgrading Ehcache’s JGroups replication module to apply a patch. I needed to upgrade JGroups. Fine. I went into IntelliJ and updated my Maven repository indexes as they were a little stale, then clicked on the version number and used auto-complete to find the new versions. I found 2.7. That did not compile with the patch. I went back to the submitter. He then informed me that JBoss had changed their repo.
I had:

After hunting around I had to change it to:

It would have been nice if the old name could have been mapped to the new location.

I thought I was done. But no, in the meantime JGroups decided to become more correct and go to a package name. Now, Ehcache did this about three years ago. So the old and new are as follows:

This whole thing was a hassle. Played out over the entire development community it turns into a lot of wasted productivity. To me each of these changes is no different to people changing interfaces in code. You have to change to rebuild. As it happens, later on I found out JGroups also did that with getLocalAddress, which is no longer castable to IPAddress. 🙁
This is a pet hate of mine. Why create work for your users? I always strenuously try to avoid these changes.
As to Maven I have been observing a trend where much of what you need is no longer in the central repository. It is now mainly a federated system. The central repo is therefore kind of dead.
This is now getting to be not much better than the old days of having to go hunting for software on a multitude of websites. But now it is even worse than that. You also have to then search on those web sites for their Maven repository, which is often buried somewhere, and then their maven coordinates for the artifact you want. I think this is turning into a software anti-distribution system. And then back to the beginning of this post – having done all that you can expect to do the same each time you want to upgrade, because of a lack of regard for backward compatibility.

Comparing Ehcache’s coherency and correctness settings with Database isolation levelsLevels

Ehcache has configurable correctness and coherency settings. A good, though not complete analogy is database isolation settings.

So, within an Ehcache cache clustered with Terracotta, you have:

Incoherent – No isolation control. Dirty Reads and Dirty Writes.
Coherent writes and incoherent reads  – Read Uncommitted
Coherent – Read Committed
Coherent with transactional rollback (JTA) – Read Committed with Two Phase Commit.
What about replicated cache clusters using RMI, JGroups or JMS? These have no isolation control. Read and Writes are dirty. Writes to the same key made in different JVMs in the cluster will race each other to propagate across the cluster. Differences between JVMs are highly likely. When using this style of cluster you must program accordingly.