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.
Which is why you're only allowed one bean per request. This way you can rely on the variables not being changed by another thread.
In fact, that's the idea behind servlets: only one
instance per servlet. Clients use the same servlet instance at a time.
That's because servlets are unmanaged components. You have to use the different servlet contexts to process the request into a response, ex. the SessionContext. It's a much older spec and designed to be free/flexible.
The EJB spec on the other hand was designed to be managed components. Many resources can be injected into a bean which are building blocks for JavaEE, some of which might not allow concurrent calls themselves, you can't know for sure so it's a general policy to not allow concurrent calls on the same instance. Pooling the SLSBs ensures that the request can be processed and it's members won't be accessed concurrently. The container can guarantee safety for both thread safe and non thread safe resources if it uses this policy. EJBs also provide managed transactions, which won't be possible if 2 concurrent calls were to use the same injected DB connection. There are many reasons, all related to concurrency in some way for why SLSBs are pooled.
With a servlets these things are all responsibilities of the developer, ie. servlets are unmanaged. I guess one reason for this is because servlets were made for a protocol which is much older, ie. HTTP. So to stay compatible with and provide all the functionality available to it they left the developer with this freedom. To ease this burden many people have written frameworks to follow a chosen design, and effectively making managed components.out of your webapp components.
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.
The container manages this for you. This is another example of why SLSBs are pooled. If you want fine grained control over the life cycle of your components, you can use SFSBs or use an alternative system inside the SLSB, like Spring beans or an instance manager component which your SLSBs query for instances of the component.
But that's not to assume that EVERY SLSB has to be pooled. It may bring more
handicaps than advantages...
This is true. Many people have simple SLSBs which would work just as well, if not better when there is only a single instance with no concurrency control, which is what was addressed EJB3.1 resulting in the Singleton EJB (annotated with javax.ejb.Singleton).
Does this answer your question?