Ferghil O'Rourke wrote:
> [snip]
> So, on the whole my problems with MVC have not been performance related.
> However, I am experiencing threadsafe problems I think due to my use of the
> request dispatcher - as mentioned just now by Tim.
> Under heavy concurrent loads I experience data integrity problems.
> Sometimes - and it's very difficult to reproduce - a user will be served
> a page that is clearly one that should have been submitted to another user.
>
This sounds like a bug in your servlet container, or a thread safety issue in your
action classes (see more below).
>
> What I'm pretty sure this is, is that there is no guarantee that an object
> I send onto the Req Dispatcher's queue will be necessarily pulled off by the
> JSP it is meant for. Right now I'm not entirely sure how to ensure that
> the object returned from a call to request.getAttribute("BusinessBean") at
> the top
> of a JSP is the one that belongs to this user's session. What exactly is the
> relationship between the request dispatcher and the session? Are they
> totally
> independent of each other? If the request dispatcher should operate within
> the
> context of a session (which I'm beginning to realize I had been assuming)
> then
> there may be some issue with my app server (Orion 1.1.37 - a great product
> btw)
> and it's managment of the request dispatcher queue.
>
The request.getAttribute() call gets a *request* attribute, not a *session*
attribute. Action classes, and the JSP pages you forward to, have access to both
kinds -- you need to make sure that both pieces of logic agree whether a particular
item will be passed one way or the other. But, programmed correctly, the servlet
container's request dispatcher implementation will always forward the correct
request (and therefore the correct session) to the correct JSP page.
The most important thing to keep in mind, however, is that the developer of action
procedures *must* be aware that multiple requests to the same action might be
happening simultaneously, for the same or different users. This is the same basic
rule that you need to be aware of when programming regular servlets -- there is
only one instance.
Where this matters is how you declare and use variables. If you declare variables
locally inside a method, there is a copy of that variable on the stack for each
simultaneous request, and they will not interfere with each other. However, if you
declare a variable outside the scope of any method, there will be only *one* copy
of that variable. Trying to use such a variable to hold information that is
specific to a particular request is a recipie for the kinds of problems you
observe, because the value will get scribbled on by other requests that are going
on at the same time.
To avoid this, I make it a rule to *never ever* use instance variables in an action
class. In a servlet, I only use them to store read-only copies of stuff that is
set up in the init() method and then stays constant. Following this simple rule
will avoid a large percentage of the potential multi-thread related problems you
might have. It might be worth a quick scan through your source code base, to see
if someone might have accidentally used an instance variable instead of a local
one.
>
> On the whole I've found model 2 a very efficient development paradigm.
> But I do have concerns over thread safety.
> Any help/comments appreciated
> Thanks,
> Ferghil O'Rourke
> USMoving Inc.
>
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
