Query strings kept in threadlocal are eating heapspace

Milo · **Joined:** Thu Aug 20, 2009 3:00 am **Posts:** 11

Hello all,

I'm getting out-of-heap space errors. After examining the heap in visual-vm I found that a lot of (>500.000 after running a couple of days) String objects containing query strings are kept in threadLocals. Why? I don't use any threadlocals in my application.

Setup:
- mysql
- tomcat
- jdbc
- dbcp
- hibernate
- ehcache
- one static entityManagerFactor for the web application

I assume that hibernate can be setup to store queries in threadlocal but why should it do that and how can I switch it off? If any additional info is needed I can obviously provide it but I think this has more to do with hibernate then with my application.

Thank you very much!

Milo

sanne.grinovero · **Posted:** Mon Jul 05, 2010 5:27 pm

hibernate is not doing that - at least on purpose.
Please track where this threadlocal is located?

Milo · **Joined:** Thu Aug 20, 2009 3:00 am **Posts:** 11

Hello Sanne,

thank you very much for the answer. Now I'm going to look at other libraries that might create threadlocal vars.
I tried to find where the threadlocal vars are created but the topmost holder is the Thread object. So I don't know who created them. I do know that the Thread is a http thread.

I found a mistake I made.
ehcache config in hibernate_cfg.xml was:
<property name="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</property>

should have been something like:
<property name="hibernate.cache.provider_class">net.sf.ehcache.hibernate.EhCacheProvider</property>

Changed it to the newest form:
<property name="hibernate.cache.region.factory_class">net.sf.ehcache.hibernate.EhCacheRegionFactory</property>

Possibly this did the strange storing of threadlocal query strings. ehcache at least has something to do with storing queries and the results...

MAG,
Milo

Milo · **Joined:** Thu Aug 20, 2009 3:00 am **Posts:** 11

Is my way of using the entitymanager correct?

Code:

         EntityManager entityManager = getEntityManagerFactory().createEntityManager();
         Query query = entityManager.createQuery("SELECT a FROM Appointment a WHERE a.active = true AND a.startDate = :selectedDate");
         Calendar selectedCalendar = getSelectedCalendar();
         query.setParameter("selectedDate", selectedCalendar.getTime(), TemporalType.DATE);
         ArrayList<Appointment> appointments = (ArrayList<Appointment>)query.getResultList();
         QueueHelper.unproxyAppointments(entityManager, appointments);
         entityManager.close();

getEntityManagerFactory() gets the static EntityManagerFactory.

I assume that the query is gone after this. Why is the querystring. Not exactly this but the by hibernate created string with things like "select doctype0_.id as id120_0_, ...".

sanne.grinovero · **Posted:** Tue Jul 06, 2010 4:23 am

Quote:

I found a mistake I made.
ehcache config in hibernate_cfg.xml was:
<property name="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</property>

should have been something like:
<property name="hibernate.cache.provider_class">net.sf.ehcache.hibernate.EhCacheProvider</property>

well, no :) it was correct:
http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#performance-cache

unless you're using a very old hibernate version. Which versions are we talking about?

Milo · **Joined:** Thu Aug 20, 2009 3:00 am **Posts:** 11

thanks again.

Ok, it probably did work but I read in the ehcache documentation that using "<property name="hibernate.cache.provider_class">net.sf.ehcache.hibernate.EhCacheProvider</property>" is the new preferred way of mapping ehcache to hibernate.

After some testing and even completely disabling the ehcache with "<property name="hibernate.cache.provider_class">org.hibernate.cache.NoCacheProvider</property>" I concluded that ehcache is not the problem.

I have "<property name="hibernate.current_session_context_class">thread</property>" which makes hibernate sessions thread based. Might be this is not what I want. I keep my entities managed by keeping the entityManager around. No need for stored sessions I think.

But still my main question is: why do ALL queries end up as ThreadLocal? Why store the query string anyway? How do I find where they are created? The heapdump does not give much info obviously.

=>>>> I found something that is probably the reason for my problem. I have a ChangeInterceptor that uses a ThreadLocal to store batches of querystrings. If a transaction takes longer then a preset amount of time I show the queries for optimizing purposes.

SOLVED: I assumed that afterTransactionCompletion was always called but that is only true for committing data. I only cleared the ThreadLocal there and so all 'just' reading' threads kept on growing the threadLocal var. I now completely removed that more or less useless function and everything seems fine.
This has been in the code for almost three years now... From right at the beginning of my learning curve :)

MAG,
Milo