Re: Clarification needed, please
Why? My situation is that I have an n-tree data structure and I wish to display the entire subtree for a given node. The task is an e-mail address book in my company. I have organizational units in an n-tree and e-mail users as leafes of organizational units. I don't think this is too strange an idea. My original design was: - make one JSP do display leafes of the node (eUserDisp.jsp) - add an option to display just the portion of the HTML code (so it can be included) - make one JSP to display subnodes of a node (OUDisp.jsp) - add jsp:include page=eUserDisp.jsp?partial=trueid=.../ - add an option to display just partial HTML (just the relevant portion inside table.../table) - add an option to, instead of displaying the list of nodes, include OUDisp.jsp?partial=true for each node So, is this sane or not? I realize that making one JDBC connecion per request can pile up connections, but now I know I can share them :-) (I'm definitely insane :-)) You could do your recursion *inside* a single page (or servlet) by repeatedly calling a method to write the sub-nodes of the tree to the response. I've written JSP custom tags to do precisely this kind of thing, and it works quite reasonably. In the end I guess I will, but I was so determined to get this recursion to work, I just wouldn't back down. I've got bumps on my forehead, but I've cleared some things in my head :-) How does the idea of an internal method doing the recursion tie in with Struts concepts? Are you trying to tell me that switching my application design over to Struts and similar tools will favour that approach? 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... One question on JDBC connection. I realize I can use a global Connection object, initialized in jspInit() and destroyed in jspDestroy(). That way there would be just one JDBC connection per JPS/Servlet, no matter how many requests fly in, which is an improvement, not over my recursion approach (with n*m connections), but also over standard placing the Connection inside service() (with n connections for n requests). This would mean that as long as the JSP is loaded it will keep a connection open. Is this a good approach? What happens if I shutdown the database? I don't think that the Connection will re-connect. Nix.
RE: Clarification needed, please
-Original Message- From: Nikola Milutinovic [mailto:[EMAIL PROTECTED]] Sent: Friday, December 28, 2001 4:59 AM To: Tomcat Users List Subject: Re: Clarification needed, please This would mean that as long as the JSP is loaded it will keep a connection open. Is this a good approach? What happens if I shutdown the database? I don't think that the Connection will re-connect. Generally, no. Most (all?) JDBC drivers can not handle multiple concurrent statements from one connection. Randy -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Clarification needed, please
On Thu, 27 Dec 2001, Nikola Milutinovic wrote: Date: Thu, 27 Dec 2001 09:09:23 +0100 From: Nikola Milutinovic [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: Clarification needed, please The key is that each simultaneous request will occur on it's own processing thread, with it's own stack - which contains all the local variables. That's why using local variables is safe, and using instance variables is not. Yes. I only wished it was stated plainly before. Your best bet is to do some study on multi-threaded programming. There's nothing new or magical about multi-threaded programming in servlets - it all falls out from exactly the same concepts. One place to start is the Java Language Tutorial http://java.sun.com/docs/books/tutorial that contains chapters on threads. The second place to study is the chapter on servlet lifecycle in the Servlet Specification http://java.sun.com/products/servlet/download.html. Or at least not unless I'm willing to synchronize on them. If you want to have an app that scales to lots of users, synchronization is *not* the right answer. It implies that, deep down, your app can only support one user at a time. This is not appropriate in a web application world, unless your user population is very very small. Why? If I need thread safety I might need to share a global object. And synchronizing on it is the Java mechanism. I know it must be used with care and caution. In general, you don't need to synchronize to *read* a shared object - only to *modify* it. For example, you might use the init() method of a servlet (which is guaranteed to be called only on a single thread, and to complete before the first request is processed) to set up a HashMap containing a bunch of resources that are needed by all of your JSP pages, and then store this as a servlet context attribute. Now, you can access this HashMap, from multiple threads, without synchronization, in complete safety -- as long as nobody tries to modify it. 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. Recursion is not the right design pattern for this kind of application requirement. Why? My situation is that I have an n-tree data structure and I wish to display the entire subtree for a given node. The task is an e-mail address book in my company. I have organizational units in an n-tree and e-mail users as leafes of organizational units. I don't think this is too strange an idea. My original design was: - make one JSP do display leafes of the node (eUserDisp.jsp) - add an option to display just the portion of the HTML code (so it can be included) - make one JSP to display subnodes of a node (OUDisp.jsp) - add jsp:include page=eUserDisp.jsp?partial=trueid=.../ - add an option to display just partial HTML (just the relevant portion inside table.../table) - add an option to, instead of displaying the list of nodes, include OUDisp.jsp?partial=true for each node So, is this sane or not? I realize that making one JDBC connecion per request can pile up connections, but now I know I can share them :-) (I'm definitely insane :-)) You could do your recursion *inside* a single page (or servlet) by repeatedly calling a method to write the sub-nodes of the tree to the response. I've written JSP custom tags to do precisely this kind of thing, and it works quite reasonably. 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... The fundamental problem with the approach you are thinking about isn't so much thread safey -- it's the fact that you are going to be intermixing business logic (i.e. *what* does my application present) with presentation logic (i.e. *how* does it look). You'd be much better off, IMHO, by learning how to design your web application according to Model/View/Controller (MVC) design patterns. MVC has been around for 30 years or so in GUI-based application designs, and has proven its worth in helping you create understandable and maintainable application designs. I'd love to. Basically, the idea of my present application was to learn JSP/Servlets and to check out my concepts. I must admit, things are clearer in my head now and that is fine. But I realize you're right. Any good books/sites for learning? There are many examples of application
RE: Clarification needed, please
-Original Message-
From: Nikola Milutinovic [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 26, 2001 8:45 AM
To: Tomcat Users List
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?
Yes. Tomcat will always create exactly one instance of a servlet
for each unique URL that can access it (i.e. two servlet mappings
equals two instances).
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?
N!. 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).
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?
Yes.
And suppose in one invocation the instance modifies depth
and another variables, would it reflect in the other
invocation?
This depends upon how many CPUs your machine has and when Java
would perform the context switch between the threads. Depth could
be the value for either thread, depending on when the switch occurs
or who was the last to modify it. another will always be the correct
value.
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.
In other words, is it appropriate to place non-static
atributes of the JSP/Servlet in %! % section?
No.
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.
TYIA,
Nix.
--
To unsubscribe: mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Clarification needed, please
-Original Message- From: Randy Layman [mailto:[EMAIL PROTECTED]] snip -Original Message- From: Nikola Milutinovic [mailto:[EMAIL PROTECTED]] snip If Tomcat gets two requests, handled by the same servlet, will the same instance of that servlet handle it? Yes. Tomcat will always create exactly one instance of a servlet for each unique URL that can access it (i.e. two servlet mappings equals two instances). Doesn't this depend upon how the servlet is scoped? Tomcat will compile one jsp per *.jsp file but instantiates the servlet differently according to the servlet's scope being either application, session, or request. Randy is explaining application scope. You get one instance of the servlet and state is maintained across all accesses. Session scope will maintain state for the duration of an http session and request scope will give you a new servlet for each request with no memory shared (and no shared memory) between requests. From what I understand of the Servlet Spec. a servlet must be contained within one instance of a JVM (because of concurrency issues) but, that is not related to the servlet scope which pertains to the semantics of your web application. That's kinda how I've been understanding it. Please correct me if I'm wrong. -Mark -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Clarification needed, please
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 26, 2001 12:09 PM To: [EMAIL PROTECTED] Subject: RE: Clarification needed, please snip If Tomcat gets two requests, handled by the same servlet, will the same instance of that servlet handle it? Yes. Tomcat will always create exactly one instance of a servlet for each unique URL that can access it (i.e. two servlet mappings equals two instances). Doesn't this depend upon how the servlet is scoped? Tomcat will compile one jsp per *.jsp file but instantiates the servlet differently according to the servlet's scope being either application, session, or request. Randy is explaining application scope. You get one instance of the servlet and state is maintained across all accesses. Session scope will maintain state for the duration of an http session and request scope will give you a new servlet for each request with no memory shared (and no shared memory) between requests. From what I understand of the Servlet Spec. a servlet must be contained within one instance of a JVM (because of concurrency issues) but, that is not related to the servlet scope which pertains to the semantics of your web application. That's kinda how I've been understanding it. Please correct me if I'm wrong. I just reread all the passages of the Servlet specification that use the word scope and cannot find a single reference to servlet scoping. The only scope I know of related to web applications would be data - and that is where the application, session, page, and request scopes are defined. The scoped data is maintained in other classes (for example HttpServletRequest for request scope and HttpSession for session scope) and have no relation to the servlet's internal data structures (i.e. static and class variables). That is how I read the spec, and that is how I have found Tomcat to work. Randy -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Clarification needed, please
On Wed, 26 Dec 2001, Nikola Milutinovic wrote:
Date: Wed, 26 Dec 2001 14:45:06 +0100
From: Nikola Milutinovic [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
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: mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Clarification needed, please
On Wed, 26 Dec 2001 [EMAIL PROTECTED] wrote: Date: Wed, 26 Dec 2001 12:09:12 -0500 From: [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Clarification needed, please -Original Message- From: Randy Layman [mailto:[EMAIL PROTECTED]] snip -Original Message- From: Nikola Milutinovic [mailto:[EMAIL PROTECTED]] snip If Tomcat gets two requests, handled by the same servlet, will the same instance of that servlet handle it? Yes. Tomcat will always create exactly one instance of a servlet for each unique URL that can access it (i.e. two servlet mappings equals two instances). Doesn't this depend upon how the servlet is scoped? Tomcat will compile one jsp per *.jsp file but instantiates the servlet differently according to the servlet's scope being either application, session, or request. Not really. *Servlets* are not scoped -- only attributes (i.e. beans). Randy is explaining application scope. You get one instance of the servlet and state is maintained across all accesses. Session scope will maintain state for the duration of an http session and request scope will give you a new servlet for each request with no memory shared (and no shared memory) between requests. From what I understand of the Servlet Spec. a servlet must be contained within one instance of a JVM (because of concurrency issues) but, that is not related to the servlet scope which pertains to the semantics of your web application. You don't have it quite right. Servlet instance lifecycle information is defined in Section 2 of the Servlet 2.3 specification, which doesn't have anything to do with scopes. Scopes (in the JSP vocabulary) match up to servlet concepts like this: * application scope beans == ServletContext attributes * session scope beans == HttpSession attributes * request scope beans == ServletRequest attributes * page scope beans do not have a direct analog in the Servlet API -- but they act more like local variables in the doGet() or doPost() method than anything else. That's kinda how I've been understanding it. Please correct me if I'm wrong. -Mark Craig McClanahan -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Clarification needed, please
Ahh. OK. I'm mixing things together when I shouldn't. Isn't it unfortunate you learn most after putting your foot in your mouth? I suppose more unfortunate is not learning anything afterward. Thanks, -Mark -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 26, 2001 2:10 PM To: Tomcat Users List Subject: RE: Clarification needed, please On Wed, 26 Dec 2001 [EMAIL PROTECTED] wrote: Date: Wed, 26 Dec 2001 12:09:12 -0500 From: [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Clarification needed, please -Original Message- From: Randy Layman [mailto:[EMAIL PROTECTED]] snip -Original Message- From: Nikola Milutinovic [mailto:[EMAIL PROTECTED]] snip If Tomcat gets two requests, handled by the same servlet, will the same instance of that servlet handle it? Yes. Tomcat will always create exactly one instance of a servlet for each unique URL that can access it (i.e. two servlet mappings equals two instances). Doesn't this depend upon how the servlet is scoped? Tomcat will compile one jsp per *.jsp file but instantiates the servlet differently according to the servlet's scope being either application, session, or request. Not really. *Servlets* are not scoped -- only attributes (i.e. beans). Randy is explaining application scope. You get one instance of the servlet and state is maintained across all accesses. Session scope will maintain state for the duration of an http session and request scope will give you a new servlet for each request with no memory shared (and no shared memory) between requests. From what I understand of the Servlet Spec. a servlet must be contained within one instance of a JVM (because of concurrency issues) but, that is not related to the servlet scope which pertains to the semantics of your web application. You don't have it quite right. Servlet instance lifecycle information is defined in Section 2 of the Servlet 2.3 specification, which doesn't have anything to do with scopes. Scopes (in the JSP vocabulary) match up to servlet concepts like this: * application scope beans == ServletContext attributes * session scope beans == HttpSession attributes * request scope beans == ServletRequest attributes * page scope beans do not have a direct analog in the Servlet API -- but they act more like local variables in the doGet() or doPost() method than anything else. That's kinda how I've been understanding it. Please correct me if I'm wrong. -Mark Craig McClanahan -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Clarification needed, please
I am a new user for tomcat v4.0, I need tomcat apache to work together, when I start tomcat, it generate the following: Tomcat standalone start Apache-tomcat start, But I am still unable to execute the jsp files under apache; I think I am not setting up the parameters for WebAppDeploy correctly: WebAppDeploy examples warpConnection /examples/ Can I know what I should put instead of examples? Thank you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 26, 2001 3:10 PM To: [EMAIL PROTECTED] Subject: RE: Clarification needed, please Ahh. OK. I'm mixing things together when I shouldn't. Isn't it unfortunate you learn most after putting your foot in your mouth? I suppose more unfortunate is not learning anything afterward. Thanks, -Mark -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 26, 2001 2:10 PM To: Tomcat Users List Subject: RE: Clarification needed, please On Wed, 26 Dec 2001 [EMAIL PROTECTED] wrote: Date: Wed, 26 Dec 2001 12:09:12 -0500 From: [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Clarification needed, please -Original Message- From: Randy Layman [mailto:[EMAIL PROTECTED]] snip -Original Message- From: Nikola Milutinovic [mailto:[EMAIL PROTECTED]] snip If Tomcat gets two requests, handled by the same servlet, will the same instance of that servlet handle it? Yes. Tomcat will always create exactly one instance of a servlet for each unique URL that can access it (i.e. two servlet mappings equals two instances). Doesn't this depend upon how the servlet is scoped? Tomcat will compile one jsp per *.jsp file but instantiates the servlet differently according to the servlet's scope being either application, session, or request. Not really. *Servlets* are not scoped -- only attributes (i.e. beans). Randy is explaining application scope. You get one instance of the servlet and state is maintained across all accesses. Session scope will maintain state for the duration of an http session and request scope will give you a new servlet for each request with no memory shared (and no shared memory) between requests. From what I understand of the Servlet Spec. a servlet must be contained within one instance of a JVM (because of concurrency issues) but, that is not related to the servlet scope which pertains to the semantics of your web application. You don't have it quite right. Servlet instance lifecycle information is defined in Section 2 of the Servlet 2.3 specification, which doesn't have anything to do with scopes. Scopes (in the JSP vocabulary) match up to servlet concepts like this: * application scope beans == ServletContext attributes * session scope beans == HttpSession attributes * request scope beans == ServletRequest attributes * page scope beans do not have a direct analog in the Servlet API -- but they act more like local variables in the doGet() or doPost() method than anything else. That's kinda how I've been understanding it. Please correct me if I'm wrong. -Mark Craig McClanahan -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Clarification needed, please
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?
N!. 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.
Re: Clarification needed, please
On Thu, 27 Dec 2001, Nikola Milutinovic wrote:
Date: Thu, 27 Dec 2001 07:55:50 +0100
From: Nikola Milutinovic [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Subject: Re: Clarification needed, please
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?
N!. 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.
Writing thread-safe code is one of the most mind-bending aspects of
writing server-side applications (rather than client-server GUIs where you
control everything :-).
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.
There is no locking at all ... or any need for it.
The key is that each simultaneous request will occur on it's own
processing thread, with it's own stack - which contains all the local
variables. That's why using local variables is safe, and using instance
variables is not.
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.
If you want to have an app that scales to lots of users, synchronization
is *not* the right answer. It implies that, deep down, your app can only
support one user at a time. This is not appropriate in a web application
world, unless your user population is very very small.
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.
Recursion is not the right design pattern for this kind of application
requirement.
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...
The fundamental problem with the approach you are thinking about isn't so
much thread safey -- it's the fact that you are going to be intermixing
business logic (i.e. *what* does my application present) with presentation
logic (i.e. *how* does it look). You'd be much better off, IMHO, by
learning how to design your web application according to
Model/View/Controller (MVC) design patterns. MVC has been around for 30
years or so in GUI-based application designs, and has proven its worth in
helping you create understandable and maintainable application designs.
There are many examples of application frameworsk that help you deal with
these issues. My favorite (disclaimer: I'm the primary author, but it's
quite popular so my opinion is not totally biased :-) is the Struts
Re: Clarification needed, please
From what I understand of the Servlet Spec. a servlet must be contained within one instance of a JVM (because of concurrency issues) but, that is not related to the servlet scope which pertains to the semantics of your web application. That's kinda how I've been understanding it. Please correct me if I'm wrong. I just reread all the passages of the Servlet specification that use the word scope and cannot find a single reference to servlet scoping. The only scope I know of related to web applications would be data - and that is where the application, session, page, and request scopes are defined. The scoped data is maintained in other classes (for example HttpServletRequest for request scope and HttpSession for session scope) and have no relation to the servlet's internal data structures (i.e. static and class variables). :-) I've just re-read them, as well. It specifically states: For a servlet not hosted in a distributed environment, the servlet container must use only one instance per servlet declaration. However, for a servlet implementing SingleThreadModel interface the servlet container may instantiate multiple instances to handle a heavy request load and serialize requests to a particular instance. So, there it is, I guess. Nix.
Re: Clarification needed, please
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
Ahh. OK. I'm mixing things together when I shouldn't. Isn't it unfortunate you learn most after putting your foot in your mouth? I suppose more unfortunate is not learning anything afterward. Well, I've just spent a whole month "putting my foot into the JSP"... :-) Nix.
