"ariekenb" wrote : After doing this I only see 2 instances of my stateless session bean created, even in tests where it's called from multiple different MDBs and directly from clients. It appears StrictMaxPool is much more conservative in ThreadlocalPool. | | doktora - Maybe using StrictMaxPool would be an interesting test/workaround in your case? | | To the JBoss experts out there - is it a "problem" that ThreadlocalPool appears to create a new instance of a stateless session bean for every call from an MDB, or is this somehow being managed? What exactly is the difference with StrictMaxPool? Will using StrictMaxPool kill performance? http://jira.jboss.org/jira/browse/JBAS-5345 ThreadlocalPool should be used in a scenario where there is high concurrency on an EJB which is being called by a ThreadPool. The ThreadlocalPool will then ensure that there is one instance per Thread and no contention between these threads. It would appear that JBossMQ does not use a ThreadPool, but instantiates threads on the fly. Thus the ThreadlocalPool will keep on creating instances to match. That makes the use of StrictMaxPool mandatory. Thus only remains the issue of why ThreadlocalPool retains instances after the thread has died. ThreadlocalPool retains all instances to make sure PreDestroy is called upon destruction of the pool. I could implement something that PreDestroy is called when the instance is ready for GC, but in this scenario it would entail creating an instance for each MDB call. That is certainly a higher performance hit then contention in the StrictMaxPool. http://jira.jboss.org/jira/browse/JBAS-1175 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141227#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...