[wildfly-dev] Pooling EJB Session Beans per default

[Bill Burke]

On 8/5/2014 3:54 PM, Andrig Miller wrote:
>> Its a horrible theory. :)  How many EJB instances of a give type are
>> created per request?  Generally only 1.  1 instance of one object of
>> one
>> type!  My $5 bet is that if you went into EJB code and started
>> counting
>> how many object allocations were made per request, you'd lose count
>> very
>> quickly.   Better yet, run a single remote EJB request through a perf
>> tool and let it count the number of allocations for you.  It will be
>> greater than 1.  :)
>>
>> Maybe the StrictMaxPool has an effect on performance because it
>> creates
>> a global synchronization bottleneck.  Throughput is less and you end
>> up
>> having less concurrent per-request objects being allocated and GC'd.
>>
>
> The number per request, while relevant is only part of the story.  The number of concurrent requests happening in the server dictates the object allocation rate.  Given enough concurrency, even a very small number of object allocations per request can create an object allocation rate that can no longer be sustained.
>

I'm saying that the number of concurrent requests might not dictate 
object allocation rate.  There are probably a number of allocations that 
happen after the EJB instance is obtained.  i.e. interception chains, 
contexts, etc.   If StrictMaxPool blocks until a new instance is 
available, then there would be less allocations per request as blocking 
threads would be serialized.

Whoever is investigating StrictMaxPool, or EJB pooling in general should 
stop.  Its pointless.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com