Does ehcache match serialVersionUID?

Question

We run 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 upgrade).

We don't care about serialVersionUID . The problem is that very bad things (up to disconnection) can happen if you have two versions of an object in a replicated cache. That is, if one of the servers running the old code replicates the item to the new server, where its class has been changed.

We usually get around this by launching a new cluster for upgraded servers on a different port, but it's pretty ugly and fragile.

So, the question is: is clustered, replicated ehcache properly complying with serialVersionUID ? That is, is object replication not trying if the version of the local class is different?

Thanks for the intuitive guesses, but I am looking for the hardest data possible, preferring official documents.

Answer 1

Ehcache does not support serialVersionUID as you suggest. I tested the script that you described first-hand, when starting Ehcache, either stand-alone or distributed through Terracotta, where an exception will be thrown on the client if the version UIDs do not match.

Ideally (and I assume that this is what you are looking for) objects that do not match serialVersionUID would just skip the cache, but unfortunately this is not supported.

If you are looking for a slightly more elegant solution to this problem, try changing the name of the cache region when changing your cached object, possibly associating it with serialVersionUID. You will need to update the ehcache configuration file to add a new cache region, however it will force resources to request objects only from caches containing the supported version. This is a big help in distributed environments where you cannot update all resources at the same time with new versions and do not want to expire the cache.