Sunday, December 20, 2009

Was I defeating bean pooling in OpenEJB?

As I previously reported I had to use JNDI to obtain a reference to my stateless session bean from my Jersey Rest service.

In so doing I created a helper class that would, among other things, cache the JNDI and EJB references I needed.

That got me to wondering - since I was using the same EJB reference over and over was I somehow defeating the stateless session bean pooling that OpenEJB was surely providing me?

The only documentation I could find on this hinted that pooling worked via the bean method invocations and not the bean reference itself. But, I wanted to see it with my own eyes. I did notice that my JNDI lookup was returning a proxy object and not my bean implementaion, so this provided me some hope that I was not defeating pooling.

My first test was to invoke my EJB 10 times via the same reference and, from inside my EJB implementation identify the bean instance that was invoked. Well, the 10 invocations went to the same instance - no pooling so far.

But, my test was not very realistic so I modified it to invoke my EJB 10 times via the same reference but from 10 separate threads. This time the 10 invocations were handled by 10 different instances of my bean implementation. Whew - proof that I had not defeated pooling by caching and reusing the bean reference I was retrieving from JNDI.

Out of curiosity I increased my invocations to 100 and this time only 9 unique instances of my stateless session bean were used to handle these 100 requests.

No comments: