Kevin Duffey wrote:
> Hi All,
>
> First, Daniel, if you reading this, I am having troubles sending email to
> you..so I will ask my questions here.
>
> Concerning the approach Daniel and Craig have discussed with me here, I have
> to say I am quite pleased how easy it is and how simplistic the design is.
> Oh yeah..I finally got it working.
>
> For those of you just reading this, I posted a number of emails to the list
> concerning I needed help with some Model 2 dilemas I was having. Daniel and
> Craig both responded with a number of good emails. See the list archive if
> your interested.
>
> Ok..so here goes the questions:
>
> When my action class places a bean in the request object with
> request.setAttribute("MyBeanName", myBean); and a JSP page uses request
> scope, first..does the getAttribute() get the bean out in the <jsp:usebean
> id="MyBeanName" scope="request".. />?
Yes, the <jsp:useBean> in the JSP page grabs it back out. You have to match on
the scope where your servlet placed the bean, as well as the name you stored it
under. In the case above, it would be something like:
<jsp:useBean id="MyBeanName" scope="request" class="....."/>
or
<jsp:useBean id="MyBeanName" scope="request" type="....."/>
(The latter is nice because you can use an interface if you've got polymorphic
beans -- for the usual case I just use class= instead.)
> Also, because its request scope, does
> it destroy the bean object after each request and automatically gc the
> object(s) used? I assume the answer is yes to both of these.
>
As long as you haven't got any references to the bean stored anywhere else, it
will be available for recycling the next time the garbage collector runs.
>
> Next, I am having compiler errors when I do
> request.setAttribute(javax.servlet.jsp.PageContext.EXCEPTION, myException);
> It can't find the .jsp.PageContext.EXCEPTION stuff. I assume my classpath
> isn't set up to the right place or something. But, my question is, is there
> really any big deal if I just say setAttribute("EXCEPTION", myException). In
> my header.inc file, which is included in evey JSP page (static and dynamic
> pages alike), I can just check for the existence of the EXCEPTION attribute
> and if it exists, display the exception, couldn't I? I mean..is there any
> "harm" so to speak in doing it this way? Or do I gain some specific
> functionality by using the javax... approach which is the standard way? Does
> it forward to a specific page or something?
>
You need to compile with the $TOMCAT_HOME/lib/servlet.jar file in your classpath
to pick up the value for javax.servlet.jsp.PageContext.EXCEPTION. There's no
guarantee that this string is, or will remain, the value "EXCEPTION", so if you
want to use the standard "error page" mechanisms provided by JSP you should use
the javax.servlet.jsp.PageContext.EXCEPTION reference.
If you are just passing exceptions to your own pages, you can use whatever id tag
you want.
>
> Some stuff about threading. If I use a single controller servlet, and 100
> requests come in at one time (hypothetical..but possible), and 20 of them
> are all ENROLL actions, does each incoming request get its own thread,
Assuming your servlet container is configured to support that many simultaneous
requests, yes.
> and
> thus when it uses the ENROLL action class, and private variables in that
> class are specific to each thread/request calling on it?
We need to be clear about definitions. In the following example:
public class EnrollAction implements Action {
private String string1;
public void perform(...) {
String string2;
}
}
The "string1" string is an instance variable, and there is only one (shared) copy
of it -- assuming you follow my suggested pattern of having a single instance of
each action class. The "private" modifier has nothing to do with how many copies
there are -- it only means that no code outside this class can reference it.
The "string2" string is a local variable. It is created on the stack assigned to
the thread that is executing your request, so there is one copy per request and
they don't interfere with each other. This is the right place to declare things
you need just within the perform() method for this particular request, without
worrying about sharing.
> Or do I have to
> take special precautions to make it thread safe? My worry is that up until
> now, I have believed that by using Servlets, I am completely thread safe.
> All incoming requests each get their own thread and their own Servlet
> instance variables that are defined in the servlet. If this is true, does
> this apply to the action class that is called as well? Does each thread
> create its own instance of that class and its tied to the thread given to
> the incoming request?
>
The rule described above for action classes applies to the servlet itself as
well. Instance variables are shared across requests, while local variables
(inside doGet() or doPost()) are not shared. There is only one instance of your
servlet -- threads don't create them or destroy them, they simply call methods on
them at the same time.
>
> If not, what is the course of action to make sure everything is absolutley
> thread safe?
>
The first principle -- use local variables unless you really want to share things
between requests.
That doesn't take care of everything, however. Let's say you have a session bean
that can be modified from an action method, and you get two requests for the same
session at the same time (simplest way is in a framed presentation, because the
requests for each frame will come in pretty much simultaneously). Good OO
practice dictates that the session bean itself should ensure that there are no
problems if two threads try to modify something at the same time. An example of
this is the java.util.Hashtable class, which guarantees that the internal data
structures will not get corrupted even if two threads call put() at the same time.
There are lots of subtleties to multithreaded programming. The first few times
through it, design from a "paranoid" point of view -- what is the worst possible
case of simultaneous access to my object? Focus on things that modify the
internal state of the object; normally read-only methods (like propety getXxxx()
methods) don't have any issues, unless you are returning something complex that
might be getting modified at the same time. Just returning strings or dates won't
cause you problems.
> Daniel, I did get your links and recall reading about the threading issues.
> Its possible I just dont comprehend the exact message they are saying there.
> :)
>
There are entire books written about how to deal with this stuff, and I seem to
remember some Java World articles on the topic as well. Check their archives.
>
> Thanks again.
>
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
