What are the disadvantages of using Hibernate's secondary cache?

Question

I see a lot of articles saying that using the secondary cache in Hibernate will improve performance, but not a lot about the disadvantages of using it. I don't want to treat the secondary cache as a magical "enable here for free better performance!" button. Can anyone describe the disadvantages of using the secondary cache so that I can be aware of the implications of using it?

Answer 1

Points quoted in the other answer seems valid. However, for me, the main disadvantages are something else:

1. Performance degrade. Yes, having caching do NOT necessary to give you better performance. Hibernate needs to do extra work to store and update the cache. If the entities cached are changed frequently and you are not querying them frequently, enabling the cache is just adding unnecessary extra burden.

2. Cache invalidation. In case your application has logics that perform updates by ways not by updating the entities (e.g. direct SQL update, update through other application, bulk HQL update (I am not very sure for the last case :P ) ), Hibernate will not know the entities are changed. Hence, when you do query, you will still get the image before update.

Answer 2

Disadvantages:

1. Clustered deployments will require a way to keep the cache in sync. We've used a simple EhCache with our own invalidation routine leveraging JGroups (high effort - recommend against it) and using Infinispan. If you go the infinispan route, you need to enable XA transactions. this will require XA drivers and transaction managers, either provided by your app server or you will have to use Atomikos.
2. There are edge cases (e.g. many-to-one or one-to-many cases) where an update/delete of an entity is not reflected in the collection properly. One e.g.: http://www.tikalk.com/java/forums/hibernate-second-level-cache-collection-eviction)