Pre-Populating SLSB EJB Pool

[g.raviteja]

Hi All,

Is there a way to specify pre-population of SLSB EJB Pool so that the pool is ready with the EJB instances when there is a rush of EJB calls?

Here, I would want to avoid Instance creation at the time of EJB call.

My beans are stateless remote beans (not Singleton Startup):

@Stateless

@Remote(MyEJBInterface.class)

My pool settings are:

<subsystem xmlns="urn:jboss:domain:ejb3:1.2">

    <session-bean>

        <stateless>

            <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>

        </stateless>

        <stateful default-access-timeout="5000" cache-ref="simple"/>

        <singleton default-access-timeout="5000"/>

    </session-bean>

    <pools>

        <bean-instance-pools>

            <strict-max-pool name="slsb-strict-max-pool" max-pool-size="1000" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>

            <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>

        </bean-instance-pools>

    </pools>

    ...

</subsystem>

Thanks in advance.

Ravi

[wdfink]

No, ATM there is no setting for that.

Also remember that a value of "1000" for SLSB's seems a bit high as the counter is for each Bean type so you will have 1000*<num of Beans> pool entries

[g.raviteja]

Thank you

Reducing the slsb limit caused blocking of EJB calls, when the number of parallel calls exceeded the pool limit.

We have changed our design to use Singleton in lock read mode (our design logic allowed that):

@Singleton

@ConcurrencyManagement(ConcurrencyManagementType.CONTAINER)

@Lock(LockType.READ)

This has removed EJB instantiations and also removed the blocking.

An important fact to consider in design.

Ravi

[wdfink]

So you have indeed 1000 parallel invocations to the same bean.

In that case the @Singleton might be a possible solution, dependent on the use-case.