geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio ForniƩ <>
Subject Re: The need for pooling beans
Date Wed, 04 Nov 2009 11:19:08 GMT

> 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