[
https://issues.jboss.org/browse/WFLY-3650?page=com.atlassian.jira.plugin....
]
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)