<<Jay Walters>>
Yes :) Sometime just formulating the question helps me to figure it out on
my own.
Dave Ford
Smart Soft - The Java Training Company
http://www.smart-soft.com
----- Original Message -----
From: "Jay Walters" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 27, 2001 8:31 AM
Subject: Re: Why pool stateless session beans?
> Are you replying to yourself?
>
> I suppose the synchronized issue has to do with using instance variables
to
> store things which you might use across invocations and clients like
> resource handles, etc.
>
> It is so nice to have the container protecting us...
>
> Cheers
> Jay
>
> -----Original Message-----
> From: Dave Ford [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 27, 2001 11:23 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Why pool stateless session beans?
>
>
> How does this sound for an answer:
>
> 1. A stateless session bean can only be hit by one thread at a time, thus
> freeing bean provider from the pain and suffering of using synchronized
> keyword. This is in the spec.
>
> 2. Thus, if three "hits" for a given stateless session bean arrive at the
> same time, then the container must:
>
> 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?
>
> Dave Ford
> Smart Soft - The Java Training Company
> http://www.smart-soft.com
>
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Wednesday, June 27, 2001 1:18 AM
> Subject: RE: Why pool stateless session beans?
>
>
> > In my opinion even if stateless session beans are not maintaining any
> state,
> > For the duration of the method call execution it is associated with the
> > caller. So if multiple users are trying to access the same methos then ,
> we
> > need to queue the calls which will obviously slow down the performance.
> But
> > if we have pool then this problem is solved to some extent.
> >
> > In fact the EJB specs do not speak anything about pooling
> >
> > Nitin
> >
> > -----Original Message-----
> > From: Dave Ford [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, June 27, 2001 8:58 AM
> > To: [EMAIL PROTECTED]
> > Subject: Why pool stateless session beans?
> >
> >
> > I asked this question once before, but never got a very satisfying
answer.
> > Why not just have one instance? What is the benefit of pooling stateless
> > session beans?
> >
> > 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".
>
>
===========================================================================
> 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".
>
>
===========================================================================
> 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".
>
>
===========================================================================
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".
