That would be a no: The servlet spec. specifically dictates that a servlet
container instantiates _only_ one instance of a given servlet, unless the
servlet implements the SingleThreadModel interface, as Joe suggested. In
that case, the servlet container can either queue incoming requests or
create multiple servlet instances. This decision is left to the servlet
container's manufacturer. Some Web servers have problems keeping the spec.
Orion, for example, had (may still have) this bug where multiple instances
of a servlet were created when the servlet's first invocation was made by a
numerous clients, as in when bombing the servlet with some stress test tool
(which is what we did). I don't know of anything about JRUN.
zm.

-----Original Message-----
From: A mailing list about Java Server Pages specification and reference
[mailto:[EMAIL PROTECTED]]On Behalf Of Haseltine, Celeste
Sent: Wednesday, January 16, 2002 12:03 AM
To: [EMAIL PROTECTED]
Subject: Re: Downloading files with jsp/servlets...


Joe,

Isn't the default behavior for servlets determined by the webserver you are
using?  Some servers do have a single servlet instance per all users, but I
know the previous version of JRUN server (3.01) instantiated a new copy of
the servlet for every new/unique session id.  I don't know about the new
version of JRUN server (3.1). I did look at the Sun page you reference
below, but it did not reference the page where the Sun standard for servlet
behavior is spelled out.

Celete

-----Original Message-----
From: Joe Cheng [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 15, 2002 3:39 PM
To: [EMAIL PROTECTED]
Subject: Re: Downloading files with jsp/servlets...


Zvika,

The default behavior for servlets is to have a *single* servlet instance
serve all incoming requests for that servlet, simultaneously.  In other
words, it's not that each incoming request instantiates your servlet; on the
contrary, the servlet only gets instantiated once in the lifetime of your
webserver (well, more or less).

That's why it's a bad idea to declare member data fields for servlets; you
may as well be declaring static fields, because that's effectively what
you're doing.  Same thing with declaring variables in <%! %> blocks in JSP.

The exception is if you implement SingleThreadModel, which guarantees that a
single instance of a servlet will not be serving two requests
simultaneously; the spec doesn't make it clear whether that happens via
synchronization, or whether multiple instance get created.

http://java.sun.com/docs/books/tutorial/servlets/client-interaction/threads.
html

Hope that helps clear it up a little.

-jmc

===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST
DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:

 http://archives.java.sun.com/jsp-interest.html
 http://java.sun.com/products/jsp/faq.html
 http://www.esperanto.org.nz/jsp/jspfaq.jsp
 http://www.jguru.com/faq/index.jsp
 http://www.jspinsider.com

===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST
DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:

 http://archives.java.sun.com/jsp-interest.html
 http://java.sun.com/products/jsp/faq.html
 http://www.esperanto.org.nz/jsp/jspfaq.jsp
 http://www.jguru.com/faq/index.jsp
 http://www.jspinsider.com

===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:

 http://archives.java.sun.com/jsp-interest.html
 http://java.sun.com/products/jsp/faq.html
 http://www.esperanto.org.nz/jsp/jspfaq.jsp
 http://www.jguru.com/faq/index.jsp
 http://www.jspinsider.com

Reply via email to