> 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.
> > 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.
> > > > 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 :-))
> > 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.
