Hi!

We have developed an web application (Tomcat 4.1) whose persistence layer has been implemented using a DAO pattern and Hibernate 2.0.3. The database is Oracle 8.1.7.

During the performance tests an OutOfMemory happened. After some weeks trying ideas and refactoring we removed the Hibernate implementation in the most frequently used DAO and used the old-known JDBC. The memory leak has disappeared!! I never wanted to beleive that the OutOfMemory issue was related with Hibernate. I've reviewed how we open and close the sessions several times, tryied different connection pools and always thought that the problem was somewhere else.

I'm a little disspointed because I really defended Hibernate as the best alternative instead of normal JDBC, and now we are removing it. I'm not still happy with the out conclusion, but the true is that the OutOfMemory is no longer happening. Has anyone gone through a similar experience?

Thnx for any comment!!

Hibernate does not have any memory leaks. This is certainly your fault.

Easy there Gav. He likes Hibernate remember. :P

Anyway, I tend to agree with Gavin. Have you downloaded one of those memory testers and checked? There must be something else. And I do feel for you...tracking down memory leaks can be a pain. :)

-G

Doe's somebody know good debug tools to find this kind of problems ?
I have used this kind of tools for C++, it is possible to detect "old" hard references and use debug info to log source code fragments, garbage authors.

We have used JMP (Java Memory Profiler, http://www.khelekore.org/jmp), but the only thing that it showed was that memory was increasing only in byte[] type variable. The amount of other objects (instances of classes that belong to our application packages and we also checked Hiberante's ones) seemed to be fine.

An increasing memory of the bytes array made us thought that it could be a database related issue.

I don't know if Hibernate has any memory leak, but I really think it doesn't since it's being successfully used in differente projects. It could be our bad use of Hibernate... As I said I have checked that every opened session is closed. What else could I check?

JDBC drivers allocate lots of byte arrays. So perhaps it is a connection management issue? I dunno. Certainly Hibernate doesn't use byte arrays anywhere except for "binary" and "serializable" types.

This tools is more usefull for monitoring, "Memory Leak Detector" must find problem and show code or FileName and LineNumber. It was not good idea to rewrite code, It must be possible to find this kind of problem. I was going to implement this kind of tool, but I think it must be possible to find "Memory Leak Detector" on inet.
Looks like the problem is unclosed Blob (some drivers keep blobs in memory). You can dissable pool and try to close connections, it must clear memory allocated by driver.

Thank you for the suggestions.

We're still working in this problem and hope to get something clear asap :-)

On the other hand, we create the Hiberante's session using the openSession() method from the SessionFactory without parameters. I want to try to use the openSession(connection) to take care personally of closing the connection and see if this frees some kind of resource.

I'll let you know about this.

Try to dissable things like pool and jvm level cache first and run app with min dependancies/optimizations/workarounds.

Hi again!

This is really crazy. We did finally replaced the Hibernate implementation and used JDBC instead, and the OutOfMemory exception is still happening!!

I thougth it could be the fetch size of the PreparedStatement and have tryed something like:


but it didn't work.

This at least confirms me that the OutOfMemory was not an Hibernate's issue :-)
Unfortunately, we've still have a problem to deal with :-(

Just a short post to say that we solved our OutOfMemory error and it was not because of Hibernate, nor Oracle's JDBC driver, but our fault in a piece of code.

Thnx for your help. It really helped us!!

Greetings!!

I have the same problem,but I can't resolve it .Could you tell me how to resolve this problem?or tell me something must be caution when using hibernate.
Think you!

hi

im also having some problem with occasional outofmemoryerror. wondering if someone can point me in the right direction to look...i get this stack trace


java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start(Native Method)
at net.sf.ehcache.store.DiskStore.(DiskStore.java:152)
at net.sf.ehcache.store.DiskStore.(DiskStore.java:110)
at net.sf.ehcache.Cache.initialise(Cache.java:180)
at net.sf.ehcache.CacheManager.addCacheNoCheck(CacheManager.java:296)
at net.sf.ehcache.CacheManager.addCache(CacheManager.java:288)
at net.sf.ehcache.CacheManager.addCache(CacheManager.java:273)
at net.sf.ehcache.hibernate.Plugin.(Plugin.java:97)
at net.sf.ehcache.hibernate.Provider.buildCache(Provider.java:89)
at net.sf.hibernate.cache.QueryCache.(QueryCache.java:40)
at net.sf.hibernate.impl.SessionFactoryImpl.(SessionFactoryImpl.java:212)
at net.sf.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:768)
at com.wellsfargo.cts.cdo.xagg.persistence.dao.AbstractDAO.createSession(Unknown Source)
at com.wellsfargo.cts.cdo.xagg.persistence.dao.XaggVariableValueDAO.retrieveDataList(Unknown Source)
at com.wellsfargo.cts.cdo.xagg.model.AbstractBaseSelections.loadMappingSelections(Unknown Source)
at com.wellsfargo.cts.cdo.xagg.model.XaggVariableSettings.loadMappingSelections(Unknown Source)
at com.wellsfargo.cts.cdo.xagg.webcontrol.EditValuesAction.performTask(Unknown Source)
at com.wellsfargo.cts.cdo.xagg.webcontrol.AbstractBaseAction.execute(Unknown Source)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:971)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:402)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6350)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3635)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2585)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)

You are probably loading too much into memory. There is no way for us to find out why you do this, its in your code.