Or JBoss5, actually. https://jira.jboss.org/jira/browse/EJBTHREE-1632 The workaround is to apply the configs manually atop each bean needed.

S,
ALR

However, the XML based configuration where a new aop domain is applied to various EJBs in jboss.xml doesn’t work in JBoss4.

Configuration of the SLSB Pool or SFSB Cache is implementation-specific. In JBoss, we use the @PoolConfig and @CacheConfig annotations (and XML equivalents in jboss.xml) to specify the backing impl and parameters.

Take a look at ejb3-interceptors-aop.xml for definitions of these annotations by default (when the developer has not added them explicitly).

S,
ALR

Please read the concerns I’m addressing through object pooling – not the overhead of instanciation, but gaining finer-grained control over how many Threads are pouring through your process at one time.

It’s a reach to say “most” developers want @Singleton in EJB 3.1, inferring that this would somehow be a default strategy. In many ways, this is analogous to JBoss’ @Service (which creates a Singleton JMX MBean), and I’ve found it useful in many cases. Take, for instance, a file transfer service which may send long byte arrays over the wire – I don’t want too many requests executing through here at once, and I might throttle it by having an MDB dispatch to a Singleton resource. I could alternatively specify an @Stateless to be backed by a Strict pool of low number, but this is implementation-specific.

Also note that with @Singleton comes a series of proposals to address method-level concurrency options, giving the developer even more flexibility within an easily-defined syntax.

S,
ALR

Yep, pooling (and in particular Thread pooling) has been a proven technique for years now. My post, however, addresses *business object instance* pooling to limit the number of Threads used. The EJB Core Spec in Section 4.7.11 defines that container implementations must not allow for re-entrant invocations; each instance must be serving at most one request (Thread) at any given time. The side effect of this is a request queue once no instances are available.

And sure, this isn’t specific to EJB – you can plug most any Enterprise feature into your existing infrastructure. My goal is to illustrate point-by-point that there’s no extraneous bloat in the specification, and that EJB provides the application developer with low-level utilities that are absolutely necessary.

S,
ALR

ALR, good point! But… Actually I’am also a crazy ejb fan.. But..

This feature (thread pool) isn’t a specific ejb feature.. Any middleware solution has it i.e. Tomcat has thread pool for servlet calls. Also we can configure these for Spring remoting..

So, Your post it’s a great explanation about thread pool execution architecture pattern, But it isn’t a proof for ejb needs

crazyMike