[wildfly-dev] Pooling EJB Session Beans per default

Wolf-Dieter Fink wfink at redhat.com
Mon Jul 21 13:39:12 EDT 2014


Hi Ralph,

as I said in your community thread 
(https://community.jboss.org/thread/242999) it is not only the problem 
to add a pool for it.
At the moment there is only the strict-max-pool which limit the total 
number of beans pooled - and also the total number of beans which can be 
used in parallel.
So that means adding the pool is a performance issue, which can make the 
situation better or worse depend on the application.
So you need to adjust it depend on your needs.

If there is another implementation of a pool, i.e.  which allow to have 
x pooled instances and more if needed, the pool might be back as default.
For the moment it is makes no difference or is faster (in most cases) 
without pooling.

- Wolf

On 21/07/14 18:16, Ralph Soika wrote:
> Hi,
>
> I want to discuss the topic of Session Bean Pooling in WildFly. I know 
> that there was a discussion in the past to disable pooling of EJB 
> Session Beans per default in WildFly.
> I understand when you argue that pooling a session bean is not faster 
> than creating the bean from scratch each time a method is called. From 
> the perspective of a application server developer this is a clear and 
> easy decision. But from the view of an application developer this 
> breaks one of the main concepts of session beans - the pooling.
> As a application developer I suppose my bean is pooled and I can use 
> one of the life-cycle annotations to control my bean. This is a basic 
> concept for all kind of beans. First I thought it could be a 
> compromise to pool only these beans which have a life-cycle 
> annotation. But this isn't a solution.
> Knowing that my bean will be pooled allows me - as a component 
> developer - to use this as a caching mechanism. For example time 
> intensive routines can also cache results in a local variable to be 
> used next time a method is called. This isn't a bad practice and can 
> increase performance of my component depending on the pool settings.
>
> So my suggestion is to pool also stateless session ejbs in the future. 
> I guess form the specification there is no duty to pool beans. So 
> there is nothing wrong when not pooling beans. And again I don't want 
> to criticize. But at the end not pooling will decrease the performance 
> of WildFly. Not the container itself but the applications running in 
> WildFly.
> It takes me a long time to figure out why my application was a little 
> bit slower in WildFly than in GlassFish until I recognized the missing 
> pooling. I can activate pooling and everything is cool. But I guess 
> some other application developers will only see that there application 
> is slower in WildFly than on other application servers.
> And this will effect their decision. That is the argument to activate 
> the pool per default.
>
> best regards
> Ralph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140721/31f37f97/attachment-0001.html 


More information about the wildfly-dev mailing list