[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