Why is a stateless session beans single-threaded?

Question

According to my understanding of a stateless session, beans are used to encode business logic. They cannot store data in their instance variables because their instance is shared by multiple queries. So they seem to be more like Singleton classes. However, the difference lies in creating (or reusing from the pool) a separate instance of the session without the beans state for each request.

After googling, I could find the argument that the Java EE specification says that they should be single-threaded. But I can’t understand why they are defined as SINGLE THREADED ?

Answer 1

SLSB is single-threaded due to the context of TX, Principal is associated with the bean instance when it is called. These beans are combined even if the maximum pool size is not processed in separate threads (depending on the provider).

If SLSBs were designed to be thread safe, each call will look like a doGet / Post servlet with request information containing Tx Context, security content information, etc. That way, at least the code looks clean (developer dependent).

Answer 2

The main reason for the beans stateless session is single-threaded to make them very scalable for the container. A container can make many simplifying assumptions about the runtime. The second reason is to make life easier for the developer, because the developer does not need to worry about any synchronization or repetition in his business logic, because the bean will never be called in another thread context.

I remember that reasoning was discussed in reviews of the original EJB 1.0 specification. I would look at the specification goals section. See http://java.sun.com/products/ejb/docs.html for a list of specifications.