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=true&id=..."/>
> - 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 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
> > framework available from Apache:
> >
> > http://jakarta.apache.org/struts/
>
> No need for a disclaimer. If I waited on my colleagues to setup Oracle
> "This and That" I'd still be on 1^2 (square one).
>
> > You would do well to study other approaches to dealing with the "multiple
> > users" isseus -- the path you're going down is going to bite you.
>
> Thanks. I will.
>
> Nix.
>
Craig
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
