Java – Why stateless session beans are single threaded

Pooling does several things.

One, by having one bean per instance, you're guaranteed to be threads safe (Servlets, for example, are not thread safe).

Two, you reduce any potential startup time that a bean might have. While Session Beans are "stateless", they only need to be stateless with regards to the client. For example, in EJB, you can inject several server resources in to a Session Bean. That state is private to the bean, but there's no reason you can't keep it from invocation to invocation. So, by pooling beans you reduce these lookups to only happening when the bean is created.

Three, you can use bean pool as a means to throttle traffic. If you only have 10 Beans in a pool, you're only going to get at most 10 requests working simultaneously, the rest will be queued up.

The "stateless" in the name refers to session conversation state, i.e. state that persists between invocations of the bean, retained for the duration of the session. However, stateless session beans are still permitted to have instance variables. Those instance variables should not relate to the conversation state, but are "shared" between clients.

In other words, stateless session beans are not guaranteed thread safe.

As a result, the container should ensure that only one thread is executing a given instance of a stateless session bean at one time, hence the need for a pool of them.