Do you always use second level cache in Hibernate?

Question

Do you always use the second level cache in Hibernate, or do you use it first without use and only use it when performance degrades?

Answer 1

Do the work first and then make it quick. If you do not need caching, do not perform it.

Answer 2

In the applications where I was, the database is shared between several applications, some of them are not Java at all. Thus, the second level cache is not an option for me in such situations, because I never know when some other application can update db.

Answer 3

My use of Hibernate has always been in the context of a different framework (e.g. Spring), where enabling caching is almost trivial. Some of these projects have used ehcache caching for some critical domain classes.

Having said that, this is another area where we have to compromise between resources - balancing search performance versus memory usage. Optimization without measurement has been shown again and again by bad practice.

Gather your application’s performance metrics. Then decide how to handle slow spots. Caching may be the least of your worries.

Answer 4

If you do everything right (beware of choosing N + 1, etc.), performance should be acceptable without a second-level cache for the vast majority of cases.

Answer 5

First, we will try it and use it only with a decrease in performance.

Answer 6

To quote the famous Donald Knuth: “Programmers spend a lot of time thinking about the speed of non-critical parts of their programs or worry about the speed of their non-critical parts, and these attempts at efficiency really have a strong negative impact on debugging and maintenance. We should forget about a little efficiency, say, about 97% of the time: premature optimization is the root of all evil, but we should not miss our opportunity in these critical 3%. "

If you see performance issues, only then can you start optimizing. And you only need to optimize the largest bottleneck and, if necessary, make your way down.

However, implementing this optimization in NHibernate has little impact on debugging and maintenance in most situations and can often be implemented with very minimal code additions.

If you rely heavily on lazy loading, have read-only tables, no need to worry about concurrency applications that do not use NHibernate, performance is a problem, and you are well aware of how to optimize the use of the second level cache (which means you already know the answer to this question), then you should use the second level cache.

Answer 7

Now there is a hibernation problem associated with this. And this is the notorious LazyInitialization exception. Basically, you need to initialize all lazy associations, while entities are tied to a persistence context. Two ways to do this:

• Manually access relationships to force download them.
• Use a query that determines the choice of connection.

These two approaches lead to completely different pieces of code, so moving one to the other can be quite successful. The problem is that approach 1. leads to a large number of requests when the second level cache is not used, so people may decide to use approach 2, which leads to fever requests. However, when you turn on the second level cache again, the requests from approach 2 do not load data from the cache, but insert the resulting objects into it, making the execution of the request slower than without the cache. This leads to complex things, such as using a query cache.

Because of this, it seems to me that the best approach to me (in this particular case) is to enable the cache first for all entities, which is usually trivial, and then disable it for objects that you do not need, as development continues,