We use Ehcache as L2 cache for Hibernate in a cluster. Since we update servers one by one to avoid downtime, at some point it is possible that in the cluster one server is running older version of code, and another the updated version.
I thought the issue was Ehcache, but I narrowed it down to Hibernate. Hibernate does not cache whole entities, but arrays of field values. So if you got entity with different schema replicated into your cache, Bad Things happen on load as the array is blindly copied.
I can’t stop this on Ehcache level. I thought of setting serialVersionUID on my entity classes, but that won’t work with those lower-level arrays.
How can I indicate to Hibernate that entity version has changed and the value from cache should NOT be loaded?
I don’t think you can avoid temporary degradation of capacity in this case because what you have here is a system running servers with incompatible codebases.
Even if you could asses the incompatibility of the entity format and it’s cached version and not to load it from cache, what you would end up with is that some machines would be reading from/writing to cache, and some would go straight to the database which will cause inconsistent data access, and so on and so forth. Basically, this approach is a can of worms.
There is a better solution. The steps include:
What you get here is temporarily degradation of capacity while still keeping the system available to serve customer requests while upgrading. It can work nicely during off-peak hours. You may enhance it by routing new requests to the upgraded part of the cluster as it becomes increasingly available. There other variations but the idea is the same – divide and conquer.
The only thing that is important that new and old cluster should not be talk to each other. You’ll need help of your operations but it’s certainly doable.
Hope this helps.
Slava Imeshev
Cacheonix: Reliable Distributed Java Cache