The application I'm developing will supposedly be clustered when it comes time to release it to production. So far I've done whatever caching I've needed in the app with ehCache, which is not a cluster-aware cache. I've done that because I figured that
1) A cache that communicates between nodes in a cluster can't be much better than just getting data directly from the database.
2) It's ok for data such as drop down list choices to sometimes be different on different cluster nodes
3) Whenever a particular cached object must be synchronized across clusters, I can find some way to communicate across the clusters and tell each cache to release its version of that object. This sporadic intra-cluster communication must be less hurtful to performance than having a cluster-aware cache that is constantly communicating between cluster nodes.
But when I think about it for a bit, I become unsure. I don't really know much about the performance of cluster-aware caches. And I have trouble figuring out when it's ok to have unsynced data in different clusters. Not only that, I think something's wrong with trying to make this assessment for all the different categories of cached objects. It's not code smell, but it's some kind of conceptual smell. Come to think of it, it will end up as code smell that comes from a faulty concept.
But in practice I haven't been making that assessment because I'm not really sure how I'm going to communicate between cluster nodes, although I guess I'll probably end up using JGroups.
So what do people in the forum do about caching inside a cluster? Can you get away with a cache that's not cluster aware? If not, what have you used that's worked?