Hi,

We are using Hibernate in production in a standard fashion (adopting the code style of the test directory attached with hibernate installation.)

When we retreive 1000 objects in testing environment under
JDK1.4 Tomcat 5.5 we see that the memory consumption does not increase in many MB. Although when we turn to production the memory
consumption just flies, our production environment contains the following

Hibernate version:3.1.2

Mapping documents:

Code between sessionFactory.openSession() and session.close():
Standard Code


JDK Version 1.5.0_05-b05

Operating System Linux

Tomcat Version 5.5.9-1ep

Name and version of the database you are using: MySql 5

Did you encounter memory problems under these specifications?

Our usage of hibernate is straight foward
we initial a session factory & than each time we use hibernate
we open a new session using the factory & close it at the end.

Our data life cycle is http request, so basically we expect hibernate to release all hibernate objects after they ran out of request scope.

We suspect it maybe - JDK GC, or class loader problem which still potins to old data objects

I will appreciate any help

by the way, do you recommend any hibernate configuration optimized
for production our current hibernate conf. is



<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory>
<!-- Database connection settings -->
<property name="connection.driver_class">com.mysql.jdbc.Driver</property>
<property name="connection.url">jdbc:mysql://localhost/baby</property>
<property name="connection.username">root</property>
<property name="connection.password"></property>
<!-- JDBC connection pool (use the built-in) -->
<property name="connection.pool_size">10</property>

<!-- SQL dialect -->
<property name="dialect">
org.hibernate.dialect.MySQLDialect
</property>


<!-- Enable Hibernate's automatic session context management -->
<property name="current_session_context_class">thread</property>
<!-- Disable the second-level cache -->
<property name="cache.provider_class">
org.hibernate.cache.NoCacheProvider
</property>
<!-- Echo all executed SQL to stdout -->
<property name="show_sql">true</property>
<!-- Drop and re-create the database schema on startup -->
<property name="hbm2ddl.auto">update</property>
<mapping resource="baby/om/db/Baby.hbm.xml" />
</session-factory>
</hibernate-configuration>

Most of the memory being used will be tomcat, hanging on to jars: tomcat loads pretty much everything at startup, for better performance.

Hibernate itself will keep a fair chunk of memory for the lifespan of the app: the session factory, all the objects created when hibernate parsed the .cfg.xml and .hbm.xml files, and so forth. Nothing phenomenal, though.

If you're worried about it, get a profiler and see what's hanging onto all that memory. There are several out there, search for "java memory profiler" in your favourite web search engine.

BTW, I don't think you need to specify the NoCacheProvider to turn of disc caching. The "approved" properties controlling that are hibernate.cache.use_query_cache and hibernate.cache.use_second_level_cache: set them both to false.

hi,

The thing that bother me most is that we see different behavior in the testing environment.

We were wondering if the JDK version could cause that?

should we upgrade to hibernate 3.1.3?

Well, every release of java has improved speed and memory use, so there might be some memory bloat using older releases. Also, tomcat has certain memory issues, most notably to to do with restarting apps within tomcat. But all I can say with certainty is that you certainly can't say for sure what's causing the memory issue unless you use a profiler. It will pay off quickly, there are good free ones, there's no reason not to profile both your test cases and "live" system.