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