I'm working on developing a web application with Spring 3 and Hibernate 3.6. At the moment I try to understand how Caching with Spring and Hibernate works. I found some sources about Caching with Hibernate and some about Spring and I try to bring my information together now. I still got some questions to both frameworks and I'd be glad if someone could answer them or tell me if the facts listed here are correct.
Most of the time, short answers (yes/no) would be sufficient. I think that this list can be useful for others too, who want to understand how caching with spring and hibernate works.
General
1) Hibernate supports the following Caches: 1st Level Cache, 2nd Level Cache, Query Cache
2) Spring itself supports the following Caching possibilities: just Method Caching
1st Level Cache
3) The 1st Level Cache is part of EVERY Hibernate application.
4) The 1st Level Cache is created for EVERY hibernate-session.
5) What is saved in the 1st Level Cache? Objects or just the values of their properties? queries and their results?
2nd Level Cache
6) I found out: the 2nd Level Cache is used ONCE per application. isn't that false? isn't it used ONCE per SessionFactory
? and: multiple sessionfactorys = multiple 2nd level caches possible?
7) what is saved in the 2nd Level Cache: in my opinion just the values belonging to one record, not the objects itself.
8) when storing values from one record in 2nd Level Cache, its possible to store related values (from objects connected over a foreign key) with it too?
9) when updating the values of one object in the 2nd level cache, it's possible to update the values of objects connected with it in the cache too?
10) when values of an object are changing, how can I update the 2nd level cache? flush? can I just update a part of the cache or must the whole cache be updated?
11) where does the 2nd level cache make sense and where doesn't it?
12) the Cache Mode: does each cache mode provide a different strategy of caching? for example with cache mode "read-only" no synchronization of database and cache is ever necessary? do other cache modes provide synchronization? I thought synchronization must be done by the developer himself?
Query Cache
13) what is the difference between the Query Cache and the 2nd Level Cache? in my opinion: in the Query Cache result sets are saved, but not with their values, just with their ids. when the query is used again and the result set is still "correct", the values belonging to the ids are queried from the 2nd Level Cache
14) For the Query Cache a 2nd Level Cache MUST be used?
15) where does the Query Cache make sense and where doesn't it?
Spring
16) Does Spring provide more Caching possibilities than method caching?
17) method caching is not linked to hibernate caching
18) but: for method caching the 2nd level is necessary, like Ehcache (which can be used by hibernate too)
19) can method caching be used without database queries?
Getting mixed up
20) if using ehcache for hibernate as 2nd level cache and Ehcache for spring for method caching, can I use the same Ehcache-instance? is there a chance that something gets mixed up?
21) when using 1st level cache and 2nd level cache, can they get mixed up? when querying the database, where does the result then come from, the 1st or 2nd level cache? does the 1st level cache work with the 2nd level cache?
22) anything else that can get mixed up by using the caches I mentioned? 🙂
Thanks for answering, no matter what question! 🙂
Best Answer
Yes.
Spring 3.1 introduces the new caching abstraction based on annotations around methods, yes.
Yes.
Yes, although you can manually clear it at any given moment.
It's a map of all objects fetched during the life of a session, if you load the same object by id for the second time, it will be loaded from L1.
You are right, typically there is just one session factory per application (database), hence the shortcut.
The same things as in L1, but they live longer. L2 is typically backed by some industrial-strength cache, while L1 is just a map (it doesn't even have to be thread-safe). It stores full entities, including lazily loaded relationships.
You do not manage L2 manually, it happens automatically.
See above.
See above - Hibernate will figure this out for you. You never interact with L2 directly.
Measure. In application that read a lot of data by primary key and read-to-write factor is very high, L2 has a significant impact on your performance.
Cache mode helps Hibernate to choose best strategy for caching and invalidating. For instance if cache is read only, Hibernate won't bother invalidating it (or it won't do this that often). But read only cache (read only entity) will of course forbid any updates.
Exactly, but this is a very broad topic. Especially the result set is still "correct" part.
Yes, without the L2 cache, the query cache has no sense and will slow down the application dramatically.
Hard question, typically when you are executing the same query a lot of times and the universe of query parameters is low (for each set of query parameters new query cache is created with all ids of records being the results).
No, Spring is more-or-less just a glue for your own code.
Spring is not linked to Hibernate, so...
L2 is Hibernate concept. If you want to cache methods, you need some underlying cache. Let it be EhCache, never mind. of course it must be thread-safe.
Spring has nothing to do with Hibernate. You may cache computations that have nothing to do with database.
You may use the same
CacheManager
and cache configuration as Hibernate to ease deployment. As long as cache names do not overlap, they are completely independent, even thought working within the same manager.They just work, as long as some abstraction does not leak :-). When you query by primary key, first L1 is examined (it is faster), then L2.
See above, abstractions tend to leak. But the worst problems come when you change the database and Hibernate does not know about it. Also clustering without proper replication will cause you a headache. And the biggest problem - very often incorrect caching actually slows down the application (query cache is the most dangerous here).