Hi All, we are new to Hibernate, and we are experiencing a memory leak in our application, which seems to be related to our use of Hibernate. I'm sure were probably doing something wrong, but not sure what. Can anyone provide some help? I can provide any other info needed?

Our max heap is currently only set to 256, we only have about 25 users.
We are using Websphere App Server 6.1, and Hibernate 3.2.6.ga

IBM Memory Analyzer provides the following message:
One instance of "org.hibernate.context.JTASessionContext" loaded by "com.ibm.ws.classloader.CompoundClassLoader @ 0x700000002709ca8" occupies 96,990,016 (63.57%) bytes. The memory is accumulated in one instance of "java.util.Hashtable$Entry[]" loaded by "com.ibm.oti.vm.BootstrapClassLoader @ 0x70000000000d238".Keywords
java.util.Hashtable$Entry[]
com.ibm.oti.vm.BootstrapClassLoader @ 0x70000000000d238
org.hibernate.context.JTASessionContext
com.ibm.ws.classloader.CompoundClassLoader @ 0x700000002709ca8

Hi,

a common scenario for such memory problem is when using 'extended sessions' for conversations
(= after commit, use the same session for the next transaction) without ever calling clear().
Sometimes hibernate users are not aware that a commit itself don't detaches the objects of the persistent context.
When you never call session.close() or session.clear() then your persistent context will hard reference all persistent
objects you accessed since the first transaction.

Beside this, by my experience a very good tool to analyze memory leaks, is the SAP memory analyzer (it's free).

Thanks pb00067, That makes sense.
We actually never call close() or clear(). We get our session from getCurrentSession(), which we thought handled this. But we are also not using transactions (db is an as400 without the support for transactions....journalling not started)
So after a little more research, it seems that the current session will only be cleared after a commit or rollback, but that never happens, I guess we'll need to account for it.

Thanks again.
Kevin...