----- Original Message -----
From: "Jason Greene" <jason.greene(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Sent: Wednesday, August 6, 2014 11:37:07 AM
Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default
On Aug 6, 2014, at 10:30 AM, Bill Burke <bburke(a)redhat.com> wrote:
> What you mean to say is that you need to scale to 100's of
> thousands of
> clients on meaningless no-op benchmarks. :) I do know that that
> SpecJ Java EE benchmarks artifically made EJB pooling important as
> process intensive calculation results were cached in these
> But real-world apps don't use this feature/anti-pattern.
If the benchmark in question is doing that, that would most
definitely explain this. I mean we know the following can perform
poorly without pooling:
1. Expensive initialization in @PostConstruct
There is no @PreConstruct or @PostContruct methods.
2. Lazy expensive initialization in a invocation (what you allude to
No caching or other lazy initialization is in the stateless session beans.
3. Expensive initialization in a constructor
I'd have to look at the code again, but I don't remember anything like this.
Large allocations of objects count as expensive initialization.
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
wildfly-dev mailing list