I prefectly agree on the first point I totally disagree on the second
one. Let me explain why.
An EJB server is not just a nice API on top of RMI. It fulfills the role
of a TP monitor. The TP monitor decides how to best utilize the
resources of the underlying machine in a manner that is totally
transparent to the application. It can decide that at any given time
there will be no more than 50 instances of a specific bean. That's fine.
If there are 51 pending requests, it must be able to serve them with
that limit, to the best of its capabilities, most probably by keeping
request 51 on hold until a bean is available.
While there are no requests, there is no need for the beans to exist.
However, the fact that a bean does not exist in the server does not
require that the handle be invalidated. A stateless session bean handle
is good for the life of the server, not the life of the bean itself.
This model works very well today with TCP/IP (using backlog), with
Servlets, with JDBC connections acquired through
PooledConnectionDataSource, even with RMI itself.
You may reach the point where 500 clients are activating 200 beans which
is more than the CPU can handle. This is solved by putting a resource
limitation on the number of concurrent invocations and putting exceeding
invocations on hold with a timeout. That's part of the TP guarantee to
the application.
You may reach the point where 100 beans are trying to gain database
access and the RDBMS server can only deal with 50 concurrent connection.
Once again, the TP monitor handles that by limiting the number of open
connections and keeping all other beans on hold until a connection is
released.
To require that a stateless bean be re-acquired through a create method
is simply to throw the EJB server's problem on the application.
Contrary to that, a stateful session bean is tied to a particular
client. 500 clients using two different instances of each bean means
1000 beans. This is where you want to say "stop". The passivation and
timeout on a stateful session bean allow you to do that in a controlled
way.
They also solve a more inherit problem, the lack of distributed garbage
control. At least in IIOP land there is no other way to cancel the
servant in a controlled fashion.
An application can deal with the fact that a stateful session bean is
only good for so long, just like users deal with the fact that a Servlet
session is only good for so long.
As for resources, a stateful session bean can consume IIOP servant, open
JDBC connections, open transactions, etc per each client instance (home
interface or handle). That is where timeout plays a crucial role and the
passivation/activation model provides temporary relief.
A stateless bean consumes IIOP servant and open JDBC connection only per
pooled instances, which are always lower than client instances, so it is
controlled and within bounds. The JDBC connection problem can further be
resolved through virtual connections that only exist while they are
being used.
<open source promo>
Tyrex (http://tyrex.exolab.org) is a TP monitor that does just that.
While 200 stateless session beans can keep a JDBC connection open, in
fact only those that are currently being used have an actual connection,
the remainder deal with a proxy connection that is made live on-demand.
Tyrex then puts a limitation on how many connections to a given database
(and also active transactions and any other pooled resource) are used at
any one time, with a wait queue and configurable timeout.
</open source promo>
arkin
> What I was referring to was the validity of the *client reference* to the
> stateless session bean. The specification is not clear about the rules for
> this. You're right that from the point of view of a client, stateless
> session beans have an indeterminate physical lifespan. But the objects and
> resources (such as IIOP connections, POAs, servants, etc) which enable a
> client to communicate with the bean instance(s) that provide service are
> not free, not necessarily trivial to establish, and not typically cheap to
> retain for indeterminate periods of time. It isn't just bean instances that
> need to be managed as resources. An EJB server has to be able to limit the
> validity of the references (stubs) it hands out, so as to optimally
> allocate and share the various server resources needed to support them.
>
> A client reference to a stateless session bean - obtained via a home lookup
> and subsequent create - ought to be good for some period of time. "Session
> timeout" seems like a good time interval specifier. But after that time,
> the reference should be cancellable, after which the client must either
> resolve a handle, "create" a new reference, or look up the home and
> "create" again.
>
> Marc San Soucie
> GemStone Systems, Inc.
>
> ===========================================================================
> 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".
