> > Is it OK to place non-static attributes of the class into
> > "global declaration" section or should I confine them to
> > being local variables of the "service()" method?
> NOOOOOOOOOOOO!. If you don't want to receive threading problems that
> become very difficult to diagnose, don't put anything as a static (or
> instance for that matter) variable. Only use local variables unless you
> know what you are doing (i.e. they can be used to store configuration
> information, but be aware of issues involved when one thread changes
> the configuration while another tries to use it).
(sigh) Thank you for saying it outloud. I've read many online tutorials, since my
access to books is very limited, but I've never seen this kind of explicit
explanation. Or at least I missed it. Do you know a good book/tutorial? I don't need
something that will "take me by the hand like an infant". I want something that states
facts as explicitely as you did, just now.
> > OK. So, suppose two (simultaneous) requests arive for this
> > URL. Will there be one instance of the class to handle them?
> Yes.
I must admit I'm a bit unaccustomed to this idea. I agree that one instance may handle
the request, if it can. But while the request is being handled, I thought that the
instance would be "locked for access" and that in case of a recursive servlet, Tomcat
would instantiate as many as needed. My mistake, I guess.
> > 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.
> Yes.
So, would something like this be appropriate?
<%!
Connection conn = null;
%>
<%
synchronized( conn ) {
if( conn == null )
conn = DriverManager.getConnection( URL, user, pass );
}
...
// should I delete it?
synchronized( conn ) {
if( conn != null ) {
conn.close();
conn = null;
}
}
%>
> > In other words, is it appropriate to place non-static
> > atributes of the JSP/Servlet in <%! %> section?
> No.
Or at least not unless I'm willing to synchronize on them.
> > 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.
>
> You could define a method in the <%! %> and pass the entire context
> in as parameters and then call that method from your <% %> code blocks.
> You could also define a class in the <!% %> code blocks that could
> hold your state and define the method to recurse on.
That's how I tested it :-) Given all circumstances and the fact that one careless
infinite recursion flooded my DB with connection requests, I'll rethink the recursion
bit. Due to data structure I cannot avoid it, but I really don't need n connection for
n-depth subtree. Maybe I'll use the code from above, the one with synchronization.
Or maybe I should employ connection pooling? Basically, every servlet in recursion
needs a connection, be it a new one or an existing one from the pool...
Nix.
