The locks will stay in memory as long as the EntityBean is cached. How many Entity Beans are you querying and loading up? Make sure you're not doing this in one transaction. Also, Remember. Stateless bean methods are Required by default. If you do your "sucking" your Entities within a Stateless bean call, you may be overloading it. Can you send me the test case creates this problem?
----- Original Message ----- From: Colin Daly <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 09, 2002 12:41 AM Subject: [JBoss-dev] out of memory > > Hi all, > > we are running JBoss-2.4.4_Tomcat-4.0.1-beta/jboss > with version 1.0 of the persistence manager from MVCSoft. > after experiencing OutOfMemory problems with a batch > program which sucks data out of a legacy database and > into postgresql through the EJB layer, i ran up Optimizeit > and discovered that the source of the "leak" is instances > of the following class are never getting garbage collected. > org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock > > I wrote a simple test client which just repeatedly called a > stateless session bean method called createAddress which > creates a simple cmp (no cmr) entity bean. The same > problem occurred. Please refer to the attached file (data.txt) > for the allocation backtrace of > org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock > in this simple test. > > I've tried debugging this but to be perfectly honest I'm > a little out of my depth here. It appears the reference > counts for the locks never reaches zero and therefore > the removeLockRef in the BeanLockManager never > actually removes the lock from the map. > > If anyone can help me on this, I would really appreciate > it. I'm not quite sure what to do next. Any suggestions > would be great. > > regards, > Colin Daly. > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
