We’re running ehcache 1.5 in a cluster with RMI replication and update servers one by one (think of a load balancer/proxy on top and zero-downtime updates).
We generally don’t care about serialVersionUID. Trouble is, very bad things (up to an outage) can happen if you have two versions of an entity in the replicated cache. That is, if one of the servers running old code replicates an element to the new server where its class has been changed.
We typically work this around by starting new cluster for updated servers on different port, but it is quite ugly and fragile.
So, the question is: Does clustered, replicated ehcache respect serialVersionUID properly? That is, does it not try and replicate entities if version of the local class is different?
Thanks for the intuitive guesses, but I’m looking for as hard data as possible, official docs preferred.
Ehcache does not support serialVersionUID in the way you’re suggesting. I have experienced the scenario you’ve described above first hand while running Ehcache both standalone and distributed via Terracotta where an exception will be thrown on the client if the version UIDs, do not match.
Ideally (and I assume this is what you’re looking for) objects not matching the serialVersionUID simply would miss the cache, but unfortunately this isn’t supported.
If you’re looking for a slightly more graceful solution to this problem try changing the cache region name when you change your cached entity, perhaps linking it with the serialVersionUID. You’ll need to update your ehcache config file to add the new cache region, however it will force resources to only request entities from caches containing the version they support. This is a big help in distributed environments where you can’t update all resources with the new versions simultaneously and don’t want to expire the cache.