[wildfly-dev] Pooling EJB Session Beans per default

arjan tijms arjan.tijms at gmail.com
Tue Aug 5 13:03:02 EDT 2014


On Tuesday, August 5, 2014, Bill Burke <bburke at redhat.com> wrote:
>
> Honestly though, I think this talk of EJB pooling is ridiculous.
> Component layers like CDI and JAX-RS don't have pooled architectures for
> their per-request objects.


True, but the problem with EJB is that it has always been implied that
stateless beans are pooled. And indeed, many servers have done so.

As a result, various developers have implemented their beans with the
assumption that there would be pooling. That code is now seeing
(performance) issues.

I think it's reasonable to assume that in many cases pooling is
unnecessary, but that occasionally it's needed. One solution to this could
be an explicit @Pooled annotation for general usage with (CDI) managed
beans.

Kind regards,
Arjan Tijms


>  Also, in an average application, there are
> multiple orders of magnitude more non component classes that are being
> instantiated per request.  Just think of all the Strings created by a
> simple HTTP request.
>
> You want a better focus?  How about JSON/XML marshalling?  Which could
> make things much easier to maintain then the hand-coded parsers that
> Wildfly uses to parse config.  And much faster and less memory at
> runtime for SOAP and JAX-RS request that currently rely on java reflection.
>
> You could go research perfect hashing algorithms for URL matching with
> servlets and JAX-RS.
>
> You could go do some perf analysis of all of our frameworks to make
> memory reduction and speed recommendations or even Pull Requests.
>
> You could visit each major project and make sure our automated builds
> have and can run automated stress tests and are measured against
> previous versions.
>
> Or you could just focus on these silly benchmarks that test no-op HTTP
> and EJB requests.
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org <javascript:;>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140805/f4a84fb0/attachment.html 


More information about the wildfly-dev mailing list