Hibernate version:
3.1

Hi. I've recently started experiencing with second level cache in hope to improve my app performance. I'm using ehcache and enabled usage of second level cache and query cache in configuration file.

In general, my application contains several simple POJOs, and for simplicity lets assume they have primitive properties only (that is, no collections, references, etc)

I need a way to cache my entities not necessarily by their id. I understand that the only way to use a non-standard (i.e. not entity id) key for cache lookups is to use query cache (am I wrong? Is there a method in which I can specify different cache indexing?). Unfortunetly, I've noticed that the key that hibernate inserts to the cache in this case is comprised of the entire query string (!) + the query parameters. Together with all other information stored in each cache entery by ehcache, this makes this feature completely infeasible for me, as I have many combinations of parameters.

Any suggestions? Is there a better practice to achieve this?

thanks

Miki,

Just define your own ehcache Cache in the config file and store objects in your own cache by any key you want. It's trivial and it works, at least for one isolated server - I do not have production experience with the distributed config of ehcache. If your keys and values are serializable you also get a free disk cache, if you want it.

Marius

Thanks for the response Marius

I will try to implement my own cache. Still, it is hibernate that inserts to the query cache very large keys (that contain entire query string). That is, even after implementing my own cache, It would be still very inefficient to work with query caching (though I won't have to). Maybe you understand why such implementation was chosen?

The query and it arguments define the unique idenfier for the data set collected. If either the query or the arguments are different then the cached data set is likely to be incorrected hence invalid.

I would suggest you don't use the query cache until you have identified special use cases that will benefit from it. Just enabling a cahce does not mean you will find a performace improvement - often the over head of managing the cache will lower performance - this is very true when the cache hit rate is poor.

David, Thanks for your reply.

I've also noticed that when creating hql query (session.createQuery), hibernate interns the query string (that is, for two different keys in the query cache of the same query, the string references to same String object) while for criteria this is not the case. is that so?

And another questions:
1) is there a way to control the first level cache similary to the second level cache (e.g. limit its size, etc)? if so, how? if not - what are its properties?
2) does the first level cache use query cache similarly?
3) Is there another way to control the way entities are indexed in the cache (second-level) without the query cache?

thanks -- Miki

1) No - first level (session) cache is on or off (depending on the type of session). You can clear it if you choose but no configurational aspects for limits exist. Normally this would not be an issue as the session should be a short lived item.

2) The session cache represents objects only where the data properties are keyed to the objects id (primary key). This may be used to resolve objects when a query that is cached is collected.

3) Hibernate has its own methods - you can operate your own application level caching using the second level cache infrustructure if you so choose.