What are the disadvantages of using a Hibernate secondary cache?

Question

I see a lot of articles saying that using secondary cache in Hibernate will improve performance, but not much about the disadvantages of using it. I don’t want to treat secondary cache as magic, “here you can get better performance for free!” button. Can someone describe the disadvantages of using a secondary cache so that I can know the consequences of using it?

Answer 1

Disadvantages:

• For clustered deployments, you will need to synchronize the cache. We used simple EhCache with our own invalidation procedure using JGroups (with great effort - we recommend against it) and using Infinispan. If you go on an endless route, you need to enable XA transactions. this will require the XA drivers and transaction managers provided by your application server, or you will have to use Atomikos.
• There are multiple cases (for example, many-to-one or one-to-many) where updating / deleting an object is not properly reflected in the collection. One, for example: http://www.tikalk.com/java/forums/hibernate-second-level-cache-collection-eviction )

Answer 2

The points indicated in another answer seem valid. However, for me, the main disadvantages are something else:

• Decreased performance. Yes, when caching, you DO NOT need to improve performance. Hibernate needs to do extra work to store and update the cache. If the cache elements change frequently, and you often do not request them, turning on the cache just adds extra load.

• Invalid cache. If your application has logics that perform updates in ways that do not update entities (for example, updating SQL directly, updating through another application, bulk HQL updating (I'm not sure about the latter case: P)), Hibernate will not know if the objects have changed. Therefore, when you execute the request, you will still get the image before updating.