-
1. Re: Seam 3 transaction 3.0.0.Final possible memory leaks?
yangju.richard.yang.pearson.com May 23, 2011 2:35 PM (in response to yangju.richard.yang.pearson.com)" One instance of "org.jboss.weld.context.CreationalContextImpl" loaded by "org.jboss.classloader.spi.base.BaseClassLoader @ 0xd2b85a08" occupies 387,677,848 (40.99%) bytes. The memory is accumulated in one instance of "java.lang.Object[]" loaded by "<system class loader>". I could not find a way to upload the screen shot. I am posting the text instead: Keywords java.lang.Object[] org.jboss.classloader.spi.base.BaseClassLoader @ 0xd2b85a08 org.jboss.weld.context.CreationalContextImpl Shortest Paths To the Accumulation Point Class Name Shallow Heap Retained Heap java.lang.Object[198578] @ 0xf2c419b8 1,588,648 387,677,288 elementData java.util.ArrayList @ 0xde867580 40 387,677,328 list, c java.util.Collections$SynchronizedRandomAccessList @ 0xde867568 40 387,677,368 dependentInstances org.jboss.weld.context.CreationalContextImpl @ 0xde867418 48 387,677,848 creationalContext org.jboss.weld.bean.builtin.InstanceImpl @ 0xde8673e0 56 88 transaction org.jboss.seam.transaction.TransactionInterceptor @ 0xde867330 40 584 instance org.jboss.interceptor.proxy.InterceptorInvocation$InterceptorMethodInvocation @ 0xfc2cf5a8 40 80 [0] java.lang.Object[10] @ 0xfc2cf570 104 184 elementData java.util.ArrayList @ 0xfc2cf558 40 224 interceptorMethodInvocations org.jboss.interceptor.proxy.SimpleInterceptionChain @ 0xfc2cf530 64 984 <Java Local> java.lang.Thread @ 0xdef53810 pool-109-thread-2 Thread 176 44,120 value java.util.HashMap$Entry @ 0xde867310 » 48 48 Total: 2 entries "
-
2. Re: Seam 3 transaction 3.0.0.Final possible memory leaks?
tandraschko May 23, 2011 2:51 PM (in response to yangju.richard.yang.pearson.com)i faced a similar problem using a small faces/persistence test application
-
3. Re: Seam 3 transaction 3.0.0.Final possible memory leaks?
yangju.richard.yang.pearson.com May 23, 2011 4:19 PM (in response to yangju.richard.yang.pearson.com)It turns out the OOM was because of this:
We had Bean A injects another Bean B. Both bean had @TransactionAttribute annotated on class level. After I removed @TransactionAttribute from Bean B, then the OOM does not occur anymore.
So the question is why is that? I thought the transaction can be propagated from Bean A to B even both beans are annotated as transaction required? Don't they share the same transaction context?
These two beans looks up (instead of injecting) entity manager from an entity manager factory (jndi lookup emf first, then emf.createEntityManager()). These beans are not declared as session bean and no SMPC is used..
Can anybody explain to me? If I don't annotate Bean B as transaction required, then what if I want directly to use B without going through A?
Thanks.
-
4. Re: Seam 3 transaction 3.0.0.Final possible memory leaks?
lightguard May 23, 2011 4:59 PM (in response to yangju.richard.yang.pearson.com)Please create a JIRA with this information.
-
5. Re: Seam 3 transaction 3.0.0.Final possible memory leaks?
yangju.richard.yang.pearson.com May 23, 2011 10:52 PM (in response to yangju.richard.yang.pearson.com)Opened in Solder JIRA:
https://issues.jboss.org/browse/SOLDER-106