[wildfly-dev] Pooling EJB Session Beans per default

[Ralph Soika]

Hi Wolf,

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.

Thanks again.

===
Ralph

On 21.07.2014 19:39, Wolf-Dieter Fink wrote:
> 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
>


-- 
*Imixs*...extends the way people work together
We are an open source company, read more at: www.imixs.org 
<http://www.imixs.org>
------------------------------------------------------------------------
Imixs Software Solutions GmbH
Agnes-Pockels-Bogen 1, 80992 München
*Web:* www.imixs.com <http://www.imixs.com>
*Office:* +49 (0)89-452136 16 *Mobil:* +49-177-4128245
Registergericht: Amtsgericht Muenchen, HRB 136045
Geschaeftsfuehrer: Gaby Heinle u. Ralph Soika

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140722/049fd69c/attachment.html