<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Ralph,<br>
<br>
as I said in your community thread
(<a class="moz-txt-link-freetext" href="https://community.jboss.org/thread/242999">https://community.jboss.org/thread/242999</a>) it is not only the
problem to add a pool for it.<br>
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.<br>
So that means adding the pool is a performance issue, which can
make the situation better or worse depend on the application.<br>
So you need to adjust it depend on your needs.<br>
<br>
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.<br>
For the moment it is makes no difference or is faster (in most
cases) without pooling.<br>
<br>
- Wolf<br>
<br>
On 21/07/14 18:16, Ralph Soika wrote:<br>
</div>
<blockquote cite="mid:53CD3CCE.2030902@imixs.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Hi,<br>
<br>
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.<br>
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.<br>
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.<br>
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.<br>
<br>
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.<br>
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.<br>
And this will effect their decision. That is the argument to
activate the pool per default.<br>
<br>
best regards<br>
Ralph<br>
</blockquote>
<br>
</body>
</html>