Hi All, we have a leak in our application, and was hoping someone could get me pointed in the right direction to resolve. We go through about 3gb of memory, in about 3 weeks (100 users).
The Memory Dump Diagnostic for Java tool, suggest that the likely suspect is a HashTable in the JTASessionContext. We are using CMT, so no specific transaction logic in our data access.
LEAK_ROOT as org.hibernate.impl.SessionFactoryObjectFactory
LEAK_CONTAINER as java.util.HashTable$Entry
Any suggestions on where to look?
posted 10 years ago
Just thought of something....hopefully someone can confirm?
While we are using CMT & getCurrentSession, I also have to set the commitment level (isolation level) to NONE....This is because none of the tables on the backend db are journaled, so commit control is not possible. Unfortunately, journaling is not a possiblity at this time either.
Could this be causing the session to remain open?
Looking at the backend db (as400), I appears that the tables accessed remain open after each request.
Thanks for the response Paul, yeah I guess leak was the wrong word to use...I figured it was misuse on our part, just not sure where. New to Hibernate.
Anyway, the db journalling (for as400 db2) provides the ability to rollback (among other things), and without that there is no transactions....Because the tables are not journaled, any attempt to update them, without the isolation level set to NONE, is rejected by DB2.
So is it possible that even though we are using getCurrentSession, that the session is not being closed after the DAO method ends?
Ah - so does as400 db2 implement it rollback segement via journalling? I'm more used to here the term used in conjunction with audit trails - hence my confusion.
Hibernate will hook into the commit issued by CMT and flush the session accordingly. But if there is no "T" I'm not sure what it will do. You might try swapping to explicitly controlling your session management, i.e. abandeon the session per business transaction pattern and open/close sessions yourself.