Thank you for your reply. By the way two comments:
Quintin Beukes-2 wrote: > > I'm not sure if the same applies to calling different business methods on > the same > SLSB, though I don't think it does. > It does. It's not possible that two clients are using the same SLSB at a time, even if they're using different methods. Imagine what would happen if method B was called inside method A and two clients were using methods A and B of the same instance.. they could end up in the same method of the same bean. Quintin Beukes-2 wrote: > > ...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... > Yes, that's true. And I understand this idea in case of, for example, DB connection pooling: a)Connetions are created before your request them and you reuse them. b) There will never be two clients trying to use the same connection. c) There SHOULD never be a client waiting for other clients to release a connection. But why to use bean pooling for a Session Facade (implemented with a SLSB)? We can't assure that two clients using the same method of a service bean will bring problems. In fact, that's the idea behind servlets: only one instance per servlet. Clients use the same servlet instance at a time. Of course there will be cases where it's good to ask for a new instance of a bean (or create it or whatever), for example, when we know we have not-shareable resources, like an instance variable that is a DB connection. But that's not to assume that EVERY SLSB has to be pooled. It may bring more handicaps than advantages... -- View this message in context: http://old.nabble.com/The-need-for-pooling-beans-tp26156648s134p26196878.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
