1

Hy,

Its said that you dont have to worry if the stateless EJB are thread safe because the container has a pool of different instances for each request but if they are stateless and there is no danger that multiple threads access to just one ejb,

  • why the container creates a pool of them and not just one?

Thanks

fernando1979
  • 1,727
  • 2
  • 20
  • 26
  • possible duplicate of [Why pool Stateless session beans?](http://stackoverflow.com/questions/134791/why-pool-stateless-session-beans) – matt freake Oct 08 '14 at 11:18

2 Answers2

0

Stateless and Concurrency are two different things:

Thread Safety ensure some other thread does not pollute what the previous thread has already processed

Stateless is when your function does not care(require to know) what system has already processed.or simply to state the function requires only the parameters it is carrying

Ankit
  • 1
  • 3
  • 1
    But in general the Threads have an own copy of the values passed to the functions so the example you made I think its wrong. Its like the servlets, it doesnt matter if multiple threads access to one instance because normally they dont have attributes and the values passed to the methods (parameters and so on) each Thread has its own copy – fernando1979 Oct 08 '14 at 11:04
  • your sample code is not demonstrating the problem explained (and it is not even java code). please fix it. – ben75 Oct 09 '14 at 14:50
0

A stateless session bean has no state from a client perspective. The EJB specification allows stateless beans to have state, but the client can't control which instance they get, so they can't depend on getting the same instance every time.

In EJB 3.1, the "singleton" session bean type was added, which is approximately the same as a SingleThreadModel servlets. That is, a single bean instance is created that all clients use, but unlike servlets, the default concurrency model is that only one client can access the bean at a time, but this can be changed (@ConcurrencyManagement and @Lock).

Brett Kail
  • 33,593
  • 2
  • 85
  • 90
  • Ok, so : 1. There is no danger to make a stateless bean singleton like servlets and make it accesible concurrently because the values passed to the ejb methods are local to the Thread, right? – fernando1979 Oct 08 '14 at 17:10
  • It depends on your perspective. If you've coded your stateless bean to have no writes to member variables, then you could change your stateless bean to be a singleton. Regardless, the EJB spec allows stateless beans to assume the container will do synchronization, so an EJB container implementation could not arbitrarily change all stateless beans to be like servlets. – Brett Kail Oct 08 '14 at 20:07