7

What is the reason why the Application Servers pool the Stateless EJBs?

I can understand that it is usefull to control the workload of the application for incomming invokations, but this only justifies the pooling of the EJBs that server as FAÇADE with the invoker client.

Does it have any benefit to pool the internal EJBs (those that are not exposed and only invoked internally to perform business logic)?? instead of use a shared single instance (like Spring does).

I can think about at least one downside: a highly used internal EJB could act as a bottleneck.

Mr.Eddart
  • 10,050
  • 13
  • 49
  • 77

2 Answers2

4

Stateless session bean EJBs are not necessarily thread-safe. They can be holding resources like JMS sessions which cannot be shared with more than one thread at a time so the server will pool them so that it can serve multiple requests for the same bean concurrently (JMS resources are also pooled, but I'm just using that for the sake of example).

Dev
  • 11,919
  • 3
  • 40
  • 53
  • If it is stateless, then there is not state to be threaten by concurrency, then no race conditions can appear, hence they are thread-safe, am I wrong? Yes, i know they have some state, like the injected resources, but then maybe they shouldn't be called stateless! :) i take the answer as correct. – Mr.Eddart Jan 17 '12 at 09:33
  • @edutesoy I agree with your explanation. But why the state is maintained then. – Sunny Gupta May 14 '14 at 04:53
3

I would also like to know why stateless EJBs are pooled. But i want to know why they're pooled rather than being created and destroyed on demand. The fact that instances can be reused for unrelated requests significantly complicates the implementation of stateless beans (it means you have to be incredibly careful about the use of instance fields), and i don't see any significant benefit to it.

Specifically, i don't see any performance benefit to it. I poked through the implementation of stateless beans in JBoss (6, IIRC), and its only the bean instance itself that's pooled; the plumbing to handle method invocation is recreated from scratch each time it's used. That means that the only performance saving is a single object creation, which should be a trivial amount of time. The only situation in which i can see it being non-trivial is if the bean acquires heavyweight resources, and holds on to them between invocations. However, in that case, the bean is really being used as a glorified, badly-managed, pool; the correct solution would be to pool the resource directly!

Now, EJB has been around a long time. Back when they first came out, object creation was expensive, so it made sense to pool them. But those days are long gone. Why was pooling not dropped in EJB3?

Tom Anderson
  • 46,189
  • 17
  • 92
  • 133
  • Well, I suppose if you have thousands of concurrent requests, it makes sense to pool them, or even more, to create them as @Singleton as long as you are sure they are thread safe, rather than having thousands of instances in memory. – Gonzalo Garcia Lasurtegui Jan 16 '12 at 23:29
  • 1
    If the bean is threadsafe, then yes, a singleton is ideal. But if not, the memory load from pooled and throwaway instances will be similar; pooled instances would actually give the garbage collector *more* work to do, because they live long enough to escape the nursery. – Tom Anderson Jan 16 '12 at 23:42
  • That is a big assertion. I suppose it depends on the time it takes for each request to process and therefore the time those objects spend in the pool. If most of them can be used at any point in time you might get some benefit over creating / destroying. This also depends on the traffic trends, etc. This is very too fine grained analysis IMO :) – Gonzalo Garcia Lasurtegui Jan 17 '12 at 00:01
  • I suppose it is because stateless EJB:s could create other resources, such as connections and entity managers, which could potentially be expensive. But if you want a bean that is recreated and discarded for each request, isn't there a way to set some kind of scope that does this? – Lii Oct 24 '14 at 08:46
  • @Lii: You can do that with a CDI bean, using the [`@RequestScoped` annotation](http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html). But you can't do it with EJBs, as far as i know. Although you can [inject `@RequestScoped` objects into stateless EJBs](http://stackoverflow.com/questions/8717022/is-it-possible-to-inject-a-requestscoped-bean-into-a-stateless-ejb), so you could push any expensive resources into such an object to have them cleaned up promptly. – Tom Anderson Oct 26 '14 at 22:15