IIUC a stateless session bean instance can have only caller at a given time. So if 2 clients request to invoke the same business method on the same bean at the same time, one will be served first, while the other will block. When the first one returns the 2nd caller will be released to invoke the method. The pooling of SLSB is to avoid this, so with a given pool size of X you can have X concurrent business method invocations for any given bean. I'm not sure if the same applies to calling different business methods on the same SLSB, though I don't think it does.

Spring might not have pooling, but this isn't necessary on the client side. Spring proxies the actual invocation to the server anyway so the requests/pooling will be handled by the server. If you are using Spring inside your SLSBs to do lookups of other beans, you might end up with problems if Spring is configured to return Singleton instances of that Spring Bean. If this is what you're doing, rather configure it to return a unique instance for every Spring Bean lookup, so you could benefit from the SB pooling of the server, or use a unique ApplicationContext inside every SLSB instance - though the former is probably a better option. 

Quintin Beukes

On Wed, Nov 4, 2009 at 1:19 PM, Antonio Fornié <sitaronocturnal@gmail.com> wrote:

> IIUC ejb 3.1 includes singleton ejbs.  I don't know much about them.

Yes, I knew it. It will be very usefull when it arrives. By now we have to
take other ways :)

> This is wrong.  Each client gets a separate copy of the SLSB so that
> indeed they can have instance variables and separate requests don't
> interfere with each other.  I won't try to comment on how useful
> instance variables are in an object called exactly once, but that is
> the design.

I think having variable instances in a SLSB for state values is not a good
idea, eventhough you can do it by your own risk. I even think in O'Reilly
Enterprise JavaBeans 3.0 book I read it was contraindicated. If you put a
value in a variable instance, when next client for this SLSB instance use
calls a method, the value will be there and the method invoked should
initialize it again or at least ignore it.

Of course you should have variable instances for other EJBs, DB connections,
configuration parameters and so on... but never a variable meant to be
changed during the execution of a method. So, in which scenario would it a
problem to have two threads (and two clients) using the same SLSB instance?
Or in others words, in which scenario could I have concurrence problems
inside a SLSB?

What I mean is, Spring doesn't have beans pooled and it doesn't seem to be a
problem. Why is it so important to have SLSB pooled?

Thank you all for your replies!
View this message in context: http://old.nabble.com/The-need-for-pooling-beans-tp26156648s134p26194495.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.