views:

154

answers:

2

Hello all,

I'm in the exact same situation as this old question:

http://stackoverflow.com/questions/2077558/warn-could-not-register-destruction-callback

In short: I see a warning saying that a destruction callback could not be registered for some beans.

My question is: since the beans whose destruction callback cannot be registered are two persistance beans, could this be the source of a memory leak?

I am experiencing a leak in my app. Although the session timeout is set (to 30 minutes), my profiler shows me more instances of the hibernate SessionImpl each time I run a thread dump. The number of instances of SessionImpl is exactly the number of times I tried to login between two thread dumps.

Thanks for your help...

+1  A: 

I think not - this shouldn't have anything to do with the Hibernate session. It is opened and closed by the Transaction manager.

Bozho
Hi thanks for your help :) Could the session be closed by the Transaction manager, but the SessionImpl instance still be held by a Spring bean? Spring configures my persistance bean with an EntityManager, and the bean is not destroyed correctly, so the EntityManager stays in memory, and the session instance as well...
Séb
I don't know, I've planned to debug this in the near future and get to the bottom of the issue. I'll let you know.
Bozho
Thanks. I'm going to digg further too, and update this page if I find something...
Séb
A: 

Ok here's what I've experienced yesterday:

My test (run by selenium) logs in to my application, and loads data from the DB, thus creating one hibernate Session. It then logs out. This is done once every 3 minutes.

The persistance beans are created by Spring as follows:

  <bean scope="session" 
    id="persistanceService" 
    class="com.a.b.c.PersistanceServiceImpl"
    p:entityManagerFactory-ref="entityManagerFactory" />

The entity manager factory is configured as follows:

 <bean id="entityManagerFactory"
  class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"
  p:dataSource-ref="dataSource" p:persistenceUnitName="jpa" >

  <property name="jpaVendorAdapter">
    <bean
      class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter"
      p:database="ORACLE"
      p:databasePlatform="org.hibernate.dialect.Oracle9iDialect"
      p:showSql="false"  />
  </property>
  <property name="jpaProperties">
    <props>
      <prop key="hibernate.hbm2ddl.auto">validate</prop>
    </props>
  </property>      
</bean>

I ran the test and created a thread dump every 30 minutes, that is every 10 login/logout.

If the listener is not set, I can see that session instances add up each time I login and out. The session-timeout is set to 30 minutes and I can see in the logs that the session is invalidated, so I expected the number of sessions to decrease after that time, but it still increases. The number of sessions was 30 after 1h30 minutes and kept going up afterwards.

If the listener is set, then session instances count stays low. Actually, it says at one because once the test logs out, the http session invalidation actually invalidates the hibernate session and everything is GC'ed. It has been like this for the last 15 hours.

Given all that, I think that missing this listener might well lead to memory leaks...

Bozho: what do you think of this? By the way, I'm not an experienced SO user: should I have posted this under my question? I thought that I was answering my own question here, so I added an answer, but not sure :-)

Séb