[jboss-jira] [JBoss JIRA] (WFLY-3650) Pooling EJB Session Beans per default

[David Lloyd (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-3650.
-------------------------------

    Resolution: Rejected


Your feedback is appreciated, but this is not a comment box, it's a bug tracker.  If you have a comment about WildFly design decisions, please see the mailing list at https://lists.jboss.org/mailman/listinfo/wildfly-dev .

> Pooling EJB Session Beans per default
> -------------------------------------
>
>                 Key: WFLY-3650
>                 URL: https://issues.jboss.org/browse/WFLY-3650
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.1.0.Final
>         Environment: idependent
>            Reporter: Ralph Soika
>            Assignee: David Lloyd
>            Priority: Minor
>              Labels: pooling
>
> Hi,
> I don't want to criticize WildFly. I think WildFly is the best Application server we have ever seen. But I want to discuss the topic of Session Bean Pooling. 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.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)