> a: Queue (serialize) the hits (slow).
> b: Create a new instance for each hit (slow).
> c: Create a bunch of instances in advance (not so slow).
>
> So then, if I understand correctly, the reason a container may pool
> stateless session instances is:
>
> It provides a well performing way of satisfying the ejb spec's rule for
> concurrency (#1 above).
>
> Is this correct?
according to the ejb 1.1 spec, for a SLSB instance to
be ready, the following steps happen:
- constructor called (newInstance).
- setSessionContext called.
- ejbCreate() called.
The important thing to note is that the Container
*can* perform the above steps *without* requiring
that a client call a create() on the home interface of
the SLSB. So your statement (b) is wrong. Once
an instance of a SLSB is created, it is typically reused.
(the container can of course passivate that instance)
Or depending on the load/concurrency, the container
may decide to instantiate more SLSBs to service
requests faster. But that is upto the ejb vendor.
(And I would expect most 'professional' ones to
pool stateless beans for better performance)
-krish
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
