This problem is in AS 5.1.0.GA with a EJB3 stateless session bean. An example TestSelfRefBean has public methods called method1() and method2(). The code for method1() makes a call to method2() via a "local reference" (named "self" in the code I can provide) to the same session bean, created via SessionContext.getBusinessObject(). Every time a remote call is made to method1(), the call (from within method1()) to self.method2() causes a new session bean instance to be instantiated and used to service that call.

I know this is a very outdated version of JBoss. It is running a large production J2EE application that we won't be able to migrate to JBoss 7.x for another 4 to 6 months. This problem was discovered as we finally migrated the last of the code from EJB 2.1 to EJB3, including a few session beans that are designed to have local references to themselves as I described above.

This has proven to cause performance and file locking problems. A couple of the session beans with these self references have fairly expensive initialization costs (code that executes in the method annotated with @PostConstruct), so in production, where methods on these beans can be called multiple times per second, we experience a significant performance hit and random problems related to file locking due to so many session bean instances trying to read from the same file.

My purpose in this post is to hopefully find out if there is a configuration change I can make to prevent a new session bean instance from being created every time a method makes a call on this local reference. I would assume normal behavior should be reuse of bean instances from a pool, creating new ones only when there are none available in the pool, not every time.

The local reference is a member variable of the stateless session bean, initialized in the @PostConstruct method (but I have tested using lazy initialization from within individual method calls with the same results).

I would certainly appreciate anyone's help or suggestions.  I will attach a simple project, testSelfRef.zip that demonstrates the problem. It assumes presence of an environment variable JBOSS_HOME, and builds and deploys with ant.

Thank you.

Todd