If you have just one instance, you lose concurrency.
Imagine a random number generator. These have no state as far as the client
is concerned - each call returns a random number which should be unrelated
to any previous number (as far as the client is concerned), but there is
internal state used to drive the algorithm. The state is initialized at bean
creation time using some external source.
So your bean looks like this:
class RandomBean {
private long state;
void ejbCreate() {
state = expensivelyAllocateSeed();
}
void random(int n) {
state = moderatelyExpensiveCalculation(state);
return state % n;
}
}
Having just one instance forces the calls to be serialized.
Having an instance created on each call is expensive.
Creating as many instances as there are concurrent calls, and dynamically
adjusting the number of instances, is what SLSBs offer for this situation.
- Avi
--
This signature intentionally left blank.
> -----Original Message-----
> From: Dave Ford [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 27, 2001 18:15
> To: Avi Kivity; [EMAIL PROTECTED]
> Subject: Re: Why pool stateless session beans?
>
>
> Thanks for your reply Avi.
>
> <<have no client-related state, but may maintain their own state.>>
> I am aware of this. It does not however answer my question.
> Why not just
> have ONE instance serve ALL clients? Why bother with the pool at all?
>
> Dave Ford
> Smart Soft - The Java Training Company
> http://www.smart-soft.com
>
===========================================================================
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".
