Its got two levels of caching. The first level the implicit Session caching - you access the same object in the same session you'll see a cached version (which is safe, because a Session is transaction-scoped). Forcing Session caching to be ignored can be done by calling flush() on the Session. The second level cache requires you pick a third party implementation of a clusterable cache - EHCache, JBoss Cache etc. or write your own. You implement it by marking objects as cacheable in the mapping file and adding the hibernate.cache.provider_class attribute to hibernate.properties (or however you choose to configure the SessionFactory).
Talking about session level caching, is the cache retained for multiple client requests. My requirement is not to read the data from database multiple time in a user session. If the data is read once from the database and stored in hibernate cache for a request, I hope that data is not read from the database for another *separate* request. I guess I need to store the reference to Session for this to work. Am I right ? Basically What I want is not read the data more than once for a logged in user.
I haven't understood the second level caching. Could you please explain what it is and what are the benefits. Thanks Paul.
The key word Hibernate use to describe the first level cache is that it is transactional caching. Hibernate is commonly used on a Session per business transaction model. So each client request to a business method creates a distinct Session which in turn implies caching for that request. Multiple calls to session.get() or whatever within the same client request (and therefore Hibernate Session) will use cached data if it can.
There is no restriction to using a Session over a large transaction - indeed there's an example somewhere on the Hibernate site which demonstates a Hibernate Session per HttpSession, which kind of sound like what you need. There are advantages - namely performance - with this approach, but it carries the extra risk of out-of-date objects in the user's Session, so care has to be taken persisting updated state. That's the general rule with caching in general, as I'm sure you know.
The second level cache is more complex. The Hibernate people call this a process or cluster scope cache - which means it is shared across many transactions, possible also across many JVMs. Using the second level cache at all involves a lot more work, but Hibernate does allow you to use it selectively, such that you can choose to use it with only cerating mapped objects that might benefit from it. So the usual objects which tend to find their way into patterns like a Singleton cache (config data that changes only when the app is restarted for example) could instead be held in the second level cache.
For the ins and outs of how you actually configure and use a second level cache, you are best advised to look at the docs for JBossCache or EHCache - and there's a good chapter on it in Hibernate In Action.
There is no restriction to using a Session over a large transaction - indeed there's an example somewhere on the Hibernate site which demonstates a Hibernate Session per HttpSession, which kind of sound like what you need.