[wildfly-dev] Pooling EJB Session Beans per default

Andrig Miller anmiller at redhat.com
Wed Aug 6 15:12:59 EDT 2014



----- Original Message -----
> From: "Jason Greene" <jason.greene at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: wildfly-dev at lists.jboss.org
> 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 at 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
> > old
> > SpecJ Java EE benchmarks artifically made EJB pooling important as
> > process intensive calculation results were cached in these
> > instances.
> > 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
> above)

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
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 


More information about the wildfly-dev mailing list