I have this weird and interesting problem with hibernate interfering with ehcache on Terracotta.
I have 2 clients, one jboss the other a standalone vm. Both share a common ehcache instance on Terracotta.
Now this works, depending on which client starts first after terracotta.
If the standalone vm starts first then everything is fine.
If jboss starts first then when the standalone vm tries to use the cache it fails because the cache has configured itself to use HibernateElementSerializationStrategy for the keys. As this has a classpath dependency on org.hibernate.cache.CacheKey and that is not in the standalone vm the cache blows up.
So, is there a way to configure ehcache to use a specific strategy and not hibernate? For me hibernate is legacy so ehcache should have no need to refer to it.
Peter Mount's Blog 
The reason for the behaviour you are seeing is that Ehcache (clustered with Terracotta) will use a specific Serialization strategy if the Hibernate classes are found on the classpath. That strategy enables the serialized form to be more compact, but doesn’t do anything if you’re putting non-Hibernate types in the cache. Now the serialization strategy used by a cache is known cluster-wide. If you start the JBoss node first (with a fresh Terracotta Server), it will be the one to choose it.
Sadly there isn’t a way for you to choose the Serialization Strategy yourself. Looks like this is something that should be built… It would be really nice if you could file a jira at jira.terracottatech.com Providing the exact error you see would be really useful as well.
Yes I’m going to report it as it is a potential issue. Fortunately I can get around it as the startup procedures dictate the non-hibernate infected nodes have to start first.
It is a bit weird that it’s hard coded. I would have thought having the ability to set the Serialization strategy would be in there as there may be the usecase of another package requiring a similar treatment (i.e. custom handling of a specific key) & not just hibernate.