geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quintin Beukes <>
Subject Re: The need for pooling beans
Date Wed, 04 Nov 2009 11:39:52 GMT

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Ʃ <>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:
> Sent from the Apache Geronimo - Users mailing list archive at

View raw message