Re: [wildfly-dev] Pooling EJB Session Beans per default

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