J2EE: why do we need more than 1 instance for servlet & stateless session bean?

[mingclee1]

Hi,
didn't really know where to post this J2EE question. Please let me
know if you think there is a better group.

I understand why we need to have separate instance for each stateful
session bean. But don't understand why servlet & stateless session
bean. In the servlet container, why does it need to have a servlet
pool? I thought there is only one instance per servlet in the servlet
container, and every request (thread) just access that single servlet
instance. That is why servlet is not thread safe. Is this wrong?

Also, why do we need a pool of instance for stateless session EJB? Why
can't we just keep one instance and call the instance everytime? It is
stateless, so it's always thread safe right?

Thanks

 

[Jon Martin Solaas]

Hi,
didn't really know where to post this J2EE question. Please let me
know if you think there is a better group.

I understand why we need to have separate instance for each stateful
session bean. But don't understand why servlet & stateless session
bean. In the servlet container, why does it need to have a servlet
pool? I thought there is only one instance per servlet in the servlet
container, and every request (thread) just access that single servlet
instance. That is why servlet is not thread safe. Is this wrong?

Also, why do we need a pool of instance for stateless session EJB? Why
can't we just keep one instance and call the instance everytime? It is
stateless, so it's always thread safe right?

Thanks

What do you think happen when your single instance is dead or involved
in time-consuming processing? That's why most implementations for
real-world usage facilitates pooling of this and that.

 

[Jean-Baptiste Nizet]

Stateless session beans aren't really stateless. They don't have a
*conversational* state, but they do have a state.
It's thus perfetly valid for a session bean method to do this:

this.foo = blah();
this.bar = booh();
return new Blurb(this.foo, this.bar);

if multiple threads wer authorized to use the same session bean
instance at the same time, you would have serious concurrency problems.


JB.

 

[mingclee1]

I see, because in stateless session bean, you can have instance
variables, so it's not really thread safe if only have one instance.
If all the requests run that one instance, we would have concurrency
problem.

But what about servlet? It is widely documented that servlet is not
thread safe. So, I guess we can have just one instance per servlet,
and every request will run the same instance?

Thanks

 

[Jon Martin Solaas]

I see, because in stateless session bean, you can have instance
variables, so it's not really thread safe if only have one instance.
If all the requests run that one instance, we would have concurrency
problem.

But what about servlet? It is widely documented that servlet is not
thread safe. So, I guess we can have just one instance per servlet,
and every request will run the same instance?

Thanks

No, most web-containers keeps many instances of the same servlet in a
servlet pool. Having all requests served by the same servlet instance
would be very ineffective and fragile. Poke around with google after
'"servlet pool" tomcat thread' or something and you'll likely find some
interesting stuff.

 

[Andrea Desole]

No, most web-containers keeps many instances of the same servlet in a
servlet pool. Having all requests served by the same servlet instance
would be very ineffective and fragile. Poke around with google after
'"servlet pool" tomcat thread' or something and you'll likely find some
interesting stuff.

actually, shouldn't they allow by default one instance of the servlet?
From the servlet 2.3 specification:

For a servlet not hosted in a distributed environment (the default), the
servlet container must use only one instance per servlet declaration.
However, for a servlet implementing the SingleThreadModel interface, the
servlet container may instantiate multiple instances to handle a heavy
request load and serialize requests to a particular instance.
In the case where a servlet was deployed as part of an application
marked in the deployment descriptor as distributable, a container may
have only one instance per servlet declaration per virtual machine (VM).
However, if the servlet in a distributable application implements the
SingleThreadModel interface, the container may instantiate multiple
instances of that servlet in each VM of the container.

 

[Jon Martin Solaas]

actually, shouldn't they allow by default one instance of the servlet?
From the servlet 2.3 specification:

For a servlet not hosted in a distributed environment (the default), the
servlet container must use only one instance per servlet declaration.
However, for a servlet implementing the SingleThreadModel interface, the
servlet container may instantiate multiple instances to handle a heavy
request load and serialize requests to a particular instance.
In the case where a servlet was deployed as part of an application
marked in the deployment descriptor as distributable, a container may
have only one instance per servlet declaration per virtual machine (VM).
However, if the servlet in a distributable application implements the
SingleThreadModel interface, the container may instantiate multiple
instances of that servlet in each VM of the container.

Yes, you are right, they (servlets) must implement SingleThreadModel to
be pooled. When the servlet doesn't implement this interface the
service() method of the single servlet instance may be called by
multiple threads at once to serve simultaneous requests in paralell, and
thus the requests are handled in an efficient way. That's why servlets
aren't thread-safe (unless implementing SingleThreadModel); If the
service() method accesses class-variables, those may change in an
unpredictable way because the service-method runs in other threads at
the same time.

When you are programming EJB's - also SLSBs - the EJB container is
supposed to handle threading issues for you, and you can safely assume
exclusive access to any class-variables within the scope of a method
call. You may implement the SingleThreadModel in your servlet to achieve
the same effect, except it's up to the vendor to facilitate pooling of
the servlets, while for SLSB it's required by the spec.

Right?

 

[Andrea Desole]

Yes, you are right, they (servlets) must implement SingleThreadModel to
be pooled. When the servlet doesn't implement this interface the
service() method of the single servlet instance may be called by
multiple threads at once to serve simultaneous requests in paralell, and
thus the requests are handled in an efficient way. That's why servlets
aren't thread-safe (unless implementing SingleThreadModel); If the
service() method accesses class-variables, those may change in an
unpredictable way because the service-method runs in other threads at
the same time.
yes


When you are programming EJB's - also SLSBs - the EJB container is
supposed to handle threading issues for you, and you can safely assume
exclusive access to any class-variables within the scope of a method
call. You may implement the SingleThreadModel in your servlet to achieve
the same effect, except it's up to the vendor to facilitate pooling of
the servlets, while for SLSB it's required by the spec.

Right?

I think so. My EJB knowledge is much poorer than my servlets knowledge