Laird,
What your proposed below is exactly what an EJB server should do.
The EJB server serves as a transaction processing monitor (aka TP), and
it's purpose is to allow more clients to use a server than the number of
resources available to the server. This is achieved through pooling. The
pooling of JDBC connections, the pooling of session beans, the pooling
of entity beans.
So in reality there is no problem with the server deciding that only 50
beans are used to server 500 clients, but when request #51 comes along
it should not blindly deny it, but simply put it on hold until the next
bean becomes available.
arkin
> That's what bothers me, if it's true. If this is true, then no, I
> *can't* use the sessionBean "as many times as I want", because if the
> client load is too high, then my sessionBean reference (which may be
> number 51 in Arkin's example above, let's say) won't have a bean
> instance to connect to.
>
> (Now, if I were writing the damn server I'd make sure that if I had a
> pool of 50 and an extra client request (#51) came in, I'd put him on
> hold for a moment and create an extra temporary 5 or 10 instances to
> handle the transient load. I'm hoping to God that ALL EJB servers
> actually do this, and that the original NoSuchObjectException that was
> thrown that precipitated this whole thread was actually due to something
> else.)
>
> Cheers,
> Laird
>
> ===========================================================================
> 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".
