As per my understanding, a servlet container creates limited instances of servlets and multiple threads of each servlet instance and reuse those threads and instances.
Because there are multiple instances of a thread, they are not “Thread-safe” (though I understand that coding them with Thread-safety is not difficult).
EJBs containers on the other hand do not create threads of EJB, but reuse EJB objects only (using pool). Since there are no multiple threads of an EJB instance, there’s no question of thread safety.
My question: Why have different behavior? Is it not a good idea to make EJBs work as Servlets (thread unsafe)?
I’m sure I’m missing something and want to understand that missing part.
Probably because they were not designed with the same goals in mind.
The servlet API is a simple API, very close to the HTTP protocol, on top of which you can build applications or frameworks. The HTTP protocol being completely stateless, I guess it made sense to also build an API that is stateless. Several frameworks built on top of the servlet API (Stripes, for example), use one instance of Action per request, which is not used concurrently.
EJBs are a much more complex and high-level framework, designed to implement transactional business-logic as simply as possible. It’s more heavyweight, and has stateful components. These obviously need to be thread-safe. I guess it was thus natural to make stateless beans thread-safe as well.
It should be noted that Spring beans, for example, are singletons by default, and must thus follow the same rules as servlets. So multiple designs are possible to provide more or less the same functionality.
Threads have nothing to do with a performance optimization. If you need to handle 3 requests concurrently, you need 3 threads, whether the request goes to a servlet or to an EJB.