Hi all,

I'm facing the following the problem. We are developing an app A1 which hits a ddbb making only read-only queries (selects). The ddbb data is updated, once a day, by other different app A2 which we can't modify. In order to improve performance of A1 app we are thinking in use a second level cache. I have several doubts:

1) We are thinking in configure the second level cache as read-only. A1 only use select queries. Is that correct? (remember A2 updates the ddbb but we haven't control over it)

2) I assume that if we use a second level cache we'll probably get stale data. correct?

3) The stale data is consistent? I mean: suppose we have two tables related X->Y, the cache could return a stale version for X and a new version of Y ? or if a stale version of X is returned also a stale version of Y is returned (data of X and Y belongs to the same snapshot)?

Thanks in advance

Hi, anybody could help with this issue? Thanks in advance.

In regard to point 1:
Yes, if with A1 you make read-only operations, then it is convenient to configure the 2L cache as read-only:
it provides the best performance.


In regard to point 2:
Yes, as soon A2 commits it updates, A1 potentially begins to work with stale data.
As you can't modify A2, there are mainly 2 possibilities:
a) once A2 has terminated his daily work, you clear the 2L Cache on A1
- this can be done manually
for example over jconsole via mbeans if you configure your cache that it registers to mbeanserver
- you can do it programmatically (sessionfactory.getCache().evictEntityRegions() , evictCollectionRegions() etc.)
if your A1 knows or get noticed when A2 has terminated his daily work

In regard to point 3:
If both X and Y are stale, then they should be consistent between each other.
It is indeed not guaranteed however that you get consistent data, it depends on how you configure the cache.
Only if you define the cache 'eternal' (= without eviction or/and invalidation) for entity X and Y
(plus its persistent collections between X and Y ) and if you already had cached the relevant records in 2L cache,
then x and y may be stale but are consistent to each other.
Otherwise it could easily happen that cached instance x was evicted in meantime whilst cached y not.
Then you work with a up-to-date x and with a stale y.

Thanks a lot for your response, very helpful. Greets.

Also keep in mind the following as you have another database updating data independent of your application.


From Hibernate in Action
Many Java applications share access to their database with other (legacy) applications.
In this case, you shouldn’t use any kind of cache beyond a transaction
scope cache. There is no way for a cache system to know when the legacy application
updated the shared data. Actually, it’s possible to implement application-level
functionality to trigger an invalidation of the process (or cluster) scope cache

You might be able to try this option so that your read-only cache becomes up-to-date [ invalidating the stale data thru application level trigger]

Thanks to both of you, I really appreciate your time. Regards.