"Finney, Michael" wrote:
> Help me out here.
>
> http://java.sun.com/docs/books/tutorial/servlets/lifecycle/service-threads.h
> tml
>
> public ShutdownExample extends HttpServlet {
> private int serviceCounter = 0;
> private Object lock = new Object();
> ...
> //Access methods for serviceCounter
> protected void enteringServiceMethod() {
> synchronized(lock) {
> serviceCounter++;
> }
> }
> protected void leavingServiceMethod() {
> synchronized(lock) {
> serviceCounter--;
> if (serviceCounter == 0 && isShuttingDown())
> notifyAll();
> }
> }
> protected int numServices() {
> synchronized(lock) {
> return serviceCounter;
> }
> }
> }
>
> "Because multiple threads will be accessing the field, and the destroy
> method will wait for the field to reach zero, field accesses should be
> synchronized. "
>
> This makes it sound like Object instance variables are in danger of multiple
> threads accessing them. Do multiple threads travel through the servlet?
Yes, multiple threads travel through your servlet (specifically, through your
service()/doGet()/doPost() methods) at the same time. There will be only one
object instance of your servlet, shared by all callers, unless your servlet
implements the SingleThreadModel which tells the servlet engine to send only one
request through at a time.
> I
> know you said one servlet per HttpSession is created,
This is not quite right ... there is an HttpSession instance per session, but
not a servlet instance per session.
> but I didn't know if
> potentially multiple threads can travel through the servlet due to multiple
> concurrent requests in a session.
>
Yep ... they do.
>
> I noticed in my research on servlets that they always talk about using
> HttpSessions to save state information. I never hear of anyone using object
> instance variables. Do you think the phrase "don't use Object instance
> variables to save state information" is implied or am I overly concerned
> here?
>
Object instance variables in your servlet class can be used under some
circumstances. Examples:
* You set something up in the init() method, and then only read it
during the service() calls.
* You only need to share between users of this particular servlet.
There are other techniques available to share things between
servlets if you need to.
* The object you are sharing has its own synchronization protection
when it is accessed from multiple threads (many implementations
of database connection pools do this for you, for example).
>
> I wanted to save state information as to whether the client is in one mode
> or another mode. I thought I could do this because there should be 1
> servlet per browser user (HttpSession)
>
There's an HttpSession instance per session, not a servlet instance per
session. That is why it is safe to maintain user state information there; in
fact, that is what HttpSession was designed for.
Note, however, that you still need to be aware of multithreading issues even
inside your HttpSession instance. The issue is that it is possible to receive
multiple requests, for the same session, at the same time. Here's at least a
couple of ways that can happen:
* Using a framed interface. Most browsers submit
multiple requests at once (Netscape defaults to 4)
and they will all be accessing the same session.
* User submits a long request, presses STOP, and
submits a second request before the first one finished
creating its response.
>
> To sum up, the questions were:
> Do multiple threads travel through the servlet?
> Do you think the phrase "don't use Object instance variables to save state
> information" is implied or am I overly concerned here? (Can a person safely
> use Object Instance variables in Servlets just like typical standard Java
> objects?)
>
You can use them if you really do want to share things -- if you don't (which is
pretty common) then you don't want to use them.
>
> This all started when I noticed that Object Instance variables (non static
> variables) were not being used anywhere in Servlets.
>
> Thanks,
> Michael Finney
>
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
