thanks for your answer. Ok I will no longer ask for this default setting ;-)
As long as it is possible to configure the pool according to the
requirements of a deployed application there is not problem. WildFly now
works great and really fast in my case.
On 21.07.2014 19:39, Wolf-Dieter Fink wrote:
as I said in your community thread
) 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
For the moment it is makes no difference or is faster (in most cases)
On 21/07/14 18:16, Ralph Soika wrote:
> 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
> 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
*Imixs*...extends the way people work together
We are an open source company, read more at: www.imixs.org
Imixs Software Solutions GmbH
Agnes-Pockels-Bogen 1, 80992 München
*Office:* +49 (0)89-452136 16 *Mobil:* +49-177-4128245
Registergericht: Amtsgericht Muenchen, HRB 136045
Geschaeftsfuehrer: Gaby Heinle u. Ralph Soika