Hibernate version: 2

I am investigating a problem with an application which is using the 'detached objects' strategy within a web application.

The problem is that although a call to close the session is made - it appears that the cache is not cleared. Thus when a subsequent call is made, the contents of the cache are returned - not reflecting any changes which may have been made to the database (another process updates one of the tables).

I have tracked down the problem to a call:

m_Session.connection().setAutoCommit(false);

This is called after the session is retrieved from the factory.

I realise that Hibernate automatically sets autocommit to false on retrieval from a connection pool, so this code is not necessary - but I would like to know what is actually happening within my application?

Thanks for any help

Neil.

Sounds like you need to understand the difference between the first and second level cache. The first level cache is local to the Hibernate session and contains actual materialized objects. The second level cache is global and exists outside the scope of a single session. Also, the second level cache contains rowset data, not materialized objects. If you set up your caching to cache absolutely everything it is very feasible that you could run out of memory, especially if your JVM is set to a low amount of memory.

First, go read about the hibernate first and second level cache in the documentation and in "Hibernate in Action." Also read up on them in the FAQ.

Second, try analyzing your application to identify exactly what really needs to be cached. Some things don't require it, and SOME things should NEVER be cached. I have an object structure that could result in litterally millions of rows being cached if I marked it's entity class as cached.

Third, verify that your JVM's heap size is set to an appropriate level. It's amazing how many people don't know that their JVM defaults to a maximum heap size of 64 MB, which is completely inapropriate for a caching J2EE app. I recommend increasing the heap size to about 70% of available system memory on a dedicated server.

Sounds like you need to understand the difference between the first and second level cache. The first level cache is local to the Hibernate session and contains actual materialized objects. The second level cache is global and exists outside the scope of a single session. Also, the second level cache contains rowset data, not materialized objects. If you set up your caching to cache absolutely everything it is very feasible that you could run out of memory, especially if your JVM is set to a low amount of memory.

First, go read about the hibernate first and second level cache in the documentation and in "Hibernate in Action." Also read up on them in the FAQ.

Second, try analyzing your application to identify exactly what really needs to be cached. Some things don't require it, and SOME things should NEVER be cached. I have an object structure that could result in litterally millions of rows being cached if I marked it's entity class as cached.

Third, verify that your JVM's heap size is set to an appropriate level. It's amazing how many people don't know that their JVM defaults to a maximum heap size of 64 MB, which is completely inapropriate for a caching J2EE app. I recommend increasing the heap size to about 70% of available system memory on a dedicated server.

Sounds like you need to understand the difference between the first and second level cache. The first level cache is local to the Hibernate session and contains actual materialized objects. The second level cache is global and exists outside the scope of a single session. Also, the second level cache contains rowset data, not materialized objects. If you set up your caching to cache absolutely everything it is very feasible that you could run out of memory, especially if your JVM is set to a low amount of memory.

First, go read about the hibernate first and second level cache in the documentation and in "Hibernate in Action." Also read up on them in the FAQ.

Second, try analyzing your application to identify exactly what really needs to be cached. Some things don't require it, and SOME things should NEVER be cached. I have an object structure that could result in litterally millions of rows being cached if I marked it's entity class as cached.

Third, verify that your JVM's heap size is set to an appropriate level. It's amazing how many people don't know that their JVM defaults to a maximum heap size of 64 MB, which is completely inapropriate for a caching J2EE app. I recommend increasing the heap size to about 70% of available system memory on a dedicated server.

I have read the the excellent Hibernate book you have mentioned - and unless I have mis-understood the concepts we are not caching anything. We have not defined a caching strategy for any of the objects - therefore there is no second level cache.

I am also not sure how the auto commit flag would affect a caching strategy even if it was in place?

Neil.

you should provide a small testcase showing you problem