Clarification needed, please

[Nikola Milutinovic <Ni...@ev.co.yu>]

Hi all.

After some testing I have reached a certain conclusion and I would like to confirm it. This all emerged after my long trail on recursive servlets

SHORT FORM
----------------

If Tomcat gets two requests, handled by the same servlet, will the same instance of that servlet handle it?
Is it OK to place non-static atributes of the class into "global declaration" section or should I confine them to being local variables of the "service()" method?

LONG FORM
---------------

Let's say I have a servlet defined by the JSP, like this:

<%@ page
...
%>
<%!
Connection conn;
Statement stat;
ResultSet rs;
int depth;
%>
<%
int another;
..
%>

This translates to:

public class myPage$jsp extends HttpJspBase {
...
Connection conn;
Statement stat;
ResultSet rs;
int depth;
....
public void _jspService(HttpServletRequest request, HttpServletResponse  response) {
  int another;
  ...
  }
}

OK. So, suppose two (simultaneous) requests arive for this URL. Will there be one instance of the class to handle them? And suppose in one invocation the instance modifies "depth" and "another" variables, would it reflect in the other invocation? Or, better yet, since, the class will open a JDBC connection, it will be opened twice, *but will be stored in the same variable*. Effectively, the first one will be deleted by the garbage collector and closed. I sense a dangerous situation here.

In other words, is it appropriate to place non-static atributes of the JSP/Servlet in <%! %> section?

You can imagine how this relates to a recursive Servlet. Right now I'm seeing this behavior in plain sight. I was just wandering what is the recomendation or correct practice.

TYIA,
Nix.

Re: Clarification needed, please

[Nikola Milutinovic <Ni...@ev.co.yu>]

Thank you Craig. That was the most explicit and exhaustive answer ever. I wish I knew that a month ago.

Nix.

Re: Clarification needed, please

["Craig R. McClanahan" <cr...@apache.org>]

On Wed, 26 Dec 2001, Nikola Milutinovic wrote:

> Date: Wed, 26 Dec 2001 14:45:06 +0100
> From: Nikola Milutinovic <Ni...@ev.co.yu>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Clarification needed, please
>
> Hi all.
>
> After some testing I have reached a certain conclusion and I would
> like to confirm it. This all emerged after my long trail on recursive
> servlets
>
> SHORT FORM
> ----------------
>
> If Tomcat gets two requests, handled by the same servlet, will the
> same instance of that servlet handle it?

The short answer is "yes".

The longer answer is a precise definition of how many servlet instances
get created by a servlet container (this applies to all, not just Tomcat):

* For servlets that do not implement SingleThreadModel, there
  will be one servlet instance per servlet definition.  Two simultaneous
  requests may well be active in the doGet() or doPost() method of your
  servlet simultaneously.

* For servlets that do implement SingleThreadModel, the container
  *may* create multiple instances of that servlet (this was just
  added to Tomcat 4, for example), but guarantees that no more than
  one request at a time will be active in any given instance.

So what is a "servlet definition"?  Any and all of the following:

* The existence of a <servlet> element in your web.xml file (two
  <servlet> elements that use the same servlet class are *different*
  definitions, so there will be one instance each).

* Each JSP page is a servlet definition.

* (Tomcat only) Each use of the invoker servlet ("/servlet/foo") with
  a different servlet class name ("foo" in this case) creates a
  unique servlet definition.  This capability is *not* defined in the
  servlet specification, so you cannot count on it being available
  everywhere.

> Is it OK to place non-static
> atributes of the class into "global declaration" section or should I
> confine them to being local variables of the "service()" method?

If your purpose is to share objects across multiple requests, this is
entirely reasonable.  However, it is *incorrect* to use instance variables
to store information about a particular request -- it will get scribbled
on by simultaneous requests to the same servlet instance.

>
> LONG FORM
> ---------------
>
> Let's say I have a servlet defined by the JSP, like this:
>
> <%@ page
> ...
> %>
> <%!
> Connection conn;
> Statement stat;
> ResultSet rs;
> int depth;
> %>
> <%
> int another;
> ..
> %>
>
> This translates to:
>
> public class myPage$jsp extends HttpJspBase {
> ...
> Connection conn;
> Statement stat;
> ResultSet rs;
> int depth;
> ....
> public void _jspService(HttpServletRequest request, HttpServletResponse  response) {
>   int another;
>   ...
>   }
> }
>
> OK. So, suppose two (simultaneous) requests arive for this URL. Will
> there be one instance of the class to handle them? And suppose in one
> invocation the instance modifies "depth" and "another" variables,
> would it reflect in the other invocation? Or, better yet, since, the
> class will open a JDBC connection, it will be opened twice, *but will
> be stored in the same variable*. Effectively, the first one will be
> deleted by the garbage collector and closed. I sense a dangerous
> situation here.
>
> In other words, is it appropriate to place non-static atributes of the
> JSP/Servlet in <%! %> section?
>

Per the above rules, this JSP page is a single servlet definition --
therefore, the "depth" variable is shared across all requests to this
page, while the "another" variable is not shared.

> You can imagine how this relates to a recursive Servlet. Right now I'm
> seeing this behavior in plain sight. I was just wandering what is the
> recomendation or correct practice.
>

What you are seeing is the standard behavior -- the basic rule to remember
is that any variables specific to a particular request should be kept in
local variables, not instance or static variables.

On the other hand, it's fine to use instance and static variables when the
intent is to share information across multiple requests.

> TYIA,
> Nix.
>

Craig McClanahan



--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>