Hello,

I have a question regarding secondary cache:

From my research, Hibernate caches objects in Secondary Cache using the "primary key" of the object as the key in the cache. My application retrieves data from the database using another column(i.e., non-primary key). Is there anyway to "configure/tell" Hibernate to use that non-primary key as the key in the cache. If there is no way to configure Hibernate like that, what would be my best bet?

Is Second-level Cache useful in a situation like this? If yes, how does Hibernate make use of Second-level cache in a situation like this? Retrieve the primary key from the database and then retrieve the object from cache using that retrieved primary key?(i.e., Is this the Hibernate default way? - Please correct me if I am wrong).


I appreciate your help.

Thank you.

javadeveloper9,

The way I understand it, "second level caching" consists in two separate and somehow independent mechanisms:

1) the caching of individual beans in the session. This is only useful if the bulk or your operations make use of get() or load(), as you say, using the ID.

2) Query caches. This consists in storing queries plus their parameters on one side, and the corresponding resultsets on the other side.
Logic indicates that this mechanism is mostly useful when you use a reduced number of queries often, with the same parameters.

I don't think that "what columns are involved in the WHERE part of your search" matters for the query caches. But they still have to be relatively few queries with the same parameters each time, for the query caching to have any effect.

Thanks for your reply gonzao_diaz.

So, can I summarize "Hibernate second level cache" as follows: (Please correct me if I am wrong)

1. If retrieving data from database using "Primary key/id" (using load() or get()), query cache IS NOT required (to avoid a database hit - assuming the object/instance has already been cached)

2. If retrieving data from database using anything other than "Primary key/id", query cache IS required to avoid a database hit - assuming the object/instance has already been cached for that query. Otherwise (i.e., if query cache is not enabled for a non-primary key retrieval) "primary key(s)" of the objects/records which satisfy the search condition will be first retrieved and then the actual objects will be retrieved from cache and/or database based on the retrieved primary keys. Is that correct??

Thank you.

1) is correct
2) Not.

I don't know how the query caché works internally, but it seems to me it is much more primitive than what you think it is, and quite independent from the kind of caching you get from load()/get()

It is just some kind of "map"with the queries' SQL code and parameters as the "key", and the resultsets as the "value".

Do you understand that, in a setup like this, it maters little whether one specific object to be returned by the query's resultset was already in the caché or not?

You think (mistakenly I believe) that, if you use query caching, that will somewhat improve your hit/miss statistics. I don't think that applies to query caching, but just to the get()/load() operations.

Add the following category to your log



Then write a small test program that loads an object twice (so that the second time the cache acts), and them perform a query that you expect to return that same value within your recordset. Perform that query twice.

Observe the activity in your log. I would expect that the activity you see for the second load() to be totally different from that on your second query.

They are separate caché mechanisms.

Thanks for your explanation and patience gonzao_diaz.

I am little bit dazed and confused now. As you said, I will write some unit tests and try to see if "query caching" helps at all.

However, I got the gist of second-level cache(hopefully). Correct me if I am wrong):

1. "Second-level Cache will be MOST LIKELY effective only if retrieving objects using primary key(s) via load() or get()"

2. "If retrieving objects using non-primary key(s) via HQL or Criteria, Query Cache MIGHT be helpful/effective"

Thanks

Correct.