My understanding is that the pool's intention is re-use, to reduce the
overhead of construction. Its maximum setting is the pool's maximum: the
maximum number of unused instances it can store. It is to control the
amount of resources the container reserves at off-peak usage.
If you are looking for an additional setting to limit concurrent access,
you need to look elsewhere:
- The maximum size of the thread pool associated with your bean controls
the maximum number of concurrent remote invocations of it through IIOP.
- The maximum size of the Web container's thread pool controls the
maximum number of concurrent invocations to your bean through its local
interface or web services endpoint.
- I believe MQ has activation properties to control the maximum number
of concurrent invocations to your MDBs.
On 22/12/2009 05:51, glassfish_at_javadesktop.org wrote:
> I am seeing similar behavior when invoking a remote EJ B. The max
> pool size is completely ignored.
>
> The whole pooling mechanism was originally created to limit resources
> (i.e. limit concurrent access to services) and to reduce the overhead
> of construction. The current design of the ejb and mdb pools clearly
> fails at all of these. This behavior of pooling is really unexpected
> and also inefficient.
>
> Can this be solved any time soon? [Message sent by forum member
> 'erikengerd' (erik_at_brakkee.org)]